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1.  INTRODUCTION 


This  training  manual  presupposes  virtually  no  programming  experi¬ 
ence  and  is  intended  to  provide  step  by  step  information  neces¬ 
sary  to  begin  using  AISIM.  It  is  not  intended  as  a  complete 
account  of  the  system  and  many  topics  covered  in  the  companion 
AISIM  User 1 s  Manual  are  covered  here  in  less  detail,  or  not  at 
al 1 .  For  further  details  on  the  operation  of  AISIM  or  on  the 
kind  of  simulation  AISIM  is  adapted  to,  the  reader  is  referred  to 
the  more  detailed  AISIM  User 1 s  Manual . 

This  manual  consists  of  seven  sections.  This  first  section 
provides  a  brief  overview  of  AISIM  and  its  main  concepts.  Sec¬ 
tions  2,  3  and  4  concern  the  Design  User  Interface  (DUI),  i.e., 
that  part  of  AISIM  in  which  models  of  engineering  systems  are 
created.  Section  5  describes  the  complete  construction  of  a  sim¬ 
ple  model.  Section  6  turns  to  the  use  of  the  Analysis  User 
Interface — the  part  of  AISIM  where  simulation  and  analysis 
occur — using  the  model  developed  in  Section  5  as  an  example. 
Finally,  Chapter  7  will  document  the  modeling,  simulation  and 
analysis  of  a  more  complex  engineering  system. 


1.1  MODELING 

A  computer  model  is  a  description  of  a  system  that  is  developed 
as  a  basis  for  calculations,  predictions  or  further  investiga¬ 
tion.  In  addition,  AISIM  is  especially  designed  to  model  systems 
that  incorporate  parallel  processing.  The  purpose  of  an  AISIM 
model  is  to  give  information  on  the  workability  of  a  system 
design,  especially  by  providing  statistics  that  serve  both  to 
predict  the  operation  of  the  modeled  system  if  implemented,  and 
to  suggest  design  modifications. 

Modeling  is  accomplished  in  AISIM  by  representing  the  ele¬ 
ments  of  the  system  being  modeled  by  AISIM  "entities."  A 
detailed  description  of  each  entity  is  provided  in  Section  3  of 
the  AISIM  User ' s  Manual .  A  general  introduction  to  the  types  of 
system  elements  modeled  by  these  AISIM  entities  is  contained  in 
section  1.3  of  this  manual. 


1.2  OVERVIEW  OF  THE  AISIM  SYSTEM 

AISIM  consists  of  five  subsystems,  each  of  which  performs  a 
distinct  service.  These  subsystems  are  (1)  the  Design  User 
Interface  (DUI);  (2)  the  Analyze  User  Interface  (AUI);  (3)  the 
Replot  User  Interface  (RUI);  (4)  the  Hardcopy  User  Interface 
(HUI ) ;  and  (5)  the  Library  User  Interface  (LUI).  Each  of  these 
subsystems  is  briefly  described  below. 

(1)  DESIGN  USER  INTERFACE 
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The  DU  I  is  the  facility  which  enables  the  user  to  create  or  alter 
models  of  systems.  It  contains  two  sublevels,  the  Architecture 
Design  Editor  (ADE)  and  the  Process  Editor  Interface  (PEI).  The 
ADE  is  used  to  construct  models  of  the  physical  layout  of  the 
given  system,  which  is  called  the  architecture.  The  PEI  is  used 
to  define  the  processes  or  logic  that  are  associated  with  that 
architecture.  Other  model  entities  are  defined  at  the  DUI  level. 

(2)  ANALYZE  USER  INTERFACE 

With  the  AUI  one  subjects  the  model  defined  in  the  DUI  mode  to 
simulation  runs  that  test  the  behavior  and  response  of  the 
modeled  system  to  various  hypothetical  conditions.  In  this  mode 
statistics  are  gathered  on  the  operation  of  the  system  in  simula¬ 
tion  and,  if  desired,  graphs  of  selected  parameters  are  generated 
(plotted)  . 

(3)  REPLOT  USER  INTERFACE 

The  REPLOT  facility  enables  the  user  to  plot  and  compare  the 
statistics  from  various  executions  of  a  model. 

(4)  HCOPY  USER  INTERFACE 

The  Hardcopy  mode  provides  the  connection  between  the  AISIM  sys¬ 
tem  and  a  printing  device.  Process  flow-charts  constructed  in 
the  DUI  are  printed  on  an  HP2631G  printer/plotter. 

(5)  LIBRARY  USER  INTERFACE 

In  the  LUI  the  user  is  able  to  break  apart  and  recombine  parts  of 
AISIM  models,  and  obtain  parts  of  models  from  a  central  system 
library.  This  feature  is  provided  because  some  model  components 
are  used  in  other  models  and  it  is  sometimes  useful  to  store 
entire  models  for  later  reuse. 


1.3  OVERVIEW  OF  AISIM  MODELING  CONSTRUCTS 


This  section  provides  a  brief  description  of  AISIM  modeling 
constructs,  to  be  followed  by  a  more  precise  description  of  them 
in  subsequent  sections. 

With  some  qualifications,  AISIM's  modeling  constructs  can  be 
divided  into  the  following  four  categories:  (1)  those  used  to 
represent  the  operations,  properties,  structure  and  internal 
relations  of  the  modeled  system  itself;  (2)  those  used  to 
represent  the  environmental  stimuli  to  which  the  system  model  is 
exposed;  (3)  those  which  represent  the  physical  layout  of  the 
system;  and  (4)  those  which  represent  and  facilitate  mathematical 
operations. 
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1.3.1  ENTITIES  REPRESENTING  ELEMENTS  EXTERNAL  TO  THE  MODELED 
SYSTEM 

1.3. 1.1  The  Load  Entity  The  Load  entity  is  used  to  represent 
aspects  of  the  world  outside  the  modeled  system  that  trigger 
processes  within  it.  The  nature  of  these  triggering  stimuli  are 
not  dealt  with  in  AISIM;  rather.  Loads  are  defined  by  specifying 
the  nodes  at  which  certain  Processes  are  to  take  place  within  a 
given  period  (see  Scenario),  together  with  specifications  of 
several  parameters  which  indicate  the  schedule  that  the  Process 
triggering  follows.  The  definition  of  a  Load  will  also  assign  a 
priority  to  each  of  the  Processes  to  be  triggered  which  will 
determine  the  priority  with  which  Processes  are  to  be  executed  in 
case  the  same  Resource  is  demanded  by  several  Processes  at  the 
same  time  or  in  overlapping  times. 

1.3. 1.2  The  Scenario  Entity  A  Scenario  is  used  to  represent  the 
external  demand  on  a  system  (i.e..  Process  triggerings  from  the 
outside)  throughout  a  simulation  exercise.  The  Scenario  divides  a 
simulation  run  into  a  number  of  periods  that  determine  the  fre¬ 
quency  with  which  Loads  will  be  initiated.  They  will  also 
trigger  Processes  in  a  way  that  is  not  systematically  related  to 
the  Loads  in  order  to  represent  abnormal  impositions  on  the  sys¬ 
tem. 


1.3.2  ENTITIES  REPRESENTING  ELEMENTS  INTERNAL  TO  THE  MODELED 
SYSTEM 

1.3. 2.1  The  Process  Entity  A  Process  is  used  to  represent  the 
operations,  decisions,  actions  or  activities  that  can  be  decom¬ 
posed  and  defined  in  terms  of  more  fundamental  AISIM  entities, 
called  Primitives.  A  Process  can  take  place  in  one  or  more  of 
the  system's  nodes  (or  may  execute  independent  of  the  nodes)  and 
can  make  use  of  one  or  more  Resources. 

1.3. 2. 1.1  The  Process  Primitives  Primitives,  of  which  there  are 
25,  are  the  elements  of  which  Processes  are  composed.  A  Process 
may  be  considered  to  be  a  collection  of  Primitives  whose  sequen¬ 
tial  execution  describes  the  logic  of  the  Process. 

The  25  Primitives  can  be  arranged  into  nine  categories 
according  to  similarity  of  function.  For  the  present,  rather 
than  give  the  meaning  of  each  Primitive  individually,  it  is  suf¬ 
ficient  to  describe  the  categories  and  in  a  general  way  charac¬ 
terize  the  roles  that  members  of  each  will  play  in  the  definition 
of  a  Process. 

1.  INTERNAL  PROCESS  EXECUTION  CONTROL.  The  Primitives, 

COMPARE 

BRANCH 

ENTRY 
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PROB 

LOOP 

serve  as  a  "framework"  for  Processes,  enabling  the  Process  to 
branch  (either  unconditionally  or  under  certain  conditions)  to 
another  portion  of  the  Process,  or  to  repeat  certain  segments  of 
the  Process  a  specified  number  of  times  (or  until  a  certain  con¬ 
dition  is  met) . 

2.  RESOURCE  ALLOCATION .  As  mentioned  earlier,  a  Process 
frequently  competes  with  others  for  Resources.  The  Primitives, 

ALLOC 

DEALLOC 

RESET 

TEST 

LOCK 

UNLOCK 

govern  the  allocation  of  Resources  among  the  various  compe'  '< 
Processes. 


3.  PROCESS  EXECUTION  CONTROL.  Since  a  principal  fea'  'e  of 
AISIM  is  its  capacity  to  model  parallel  Processing,  i.e., 
tinct  Processes  executing  at  the  same  time,  these  Primitiv 
govern  the  timing  of  various  Processes  in  the  system  relat  to 
one  another.  The  Primitives, 


CALL 

SEND 

SUSPEND 

RESUME 

WAIT 

will  either  interrupt  the  Process  in  which  they  stand,  or 
trigger,  re-initiate  or  interrupt  some  other  Process. 

5*  QUEUE  HANDLING.  The  Primitives, 

FILE 

FIND 

REMOVE 

govern  the  placement  and  retrieval  of  Items  in  Queues  that  have 
been  defined  by  the  user. 

6.  ITEM  HANDLING.  The  Primitives, 

CREATE 

DESTROY 

govern  the  introduction  and  elimination  of  a  system's  transient 
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data  elements. 


7.  VARIABLE  MANIPULATION.  The  Primitives, 


ASSIGN 

EVAL 


assign  values  to  variables  (both  numerical 
allow  for  the  mathematical  manipulation  of 


and  non-numer ical) 
numerical  ones. 


and 


8.  TIME  SEQUENCING.  The  Primitive, 


ACTION 


which  is  associated  with  the  Action  entity  described 
included  in  Process  definitions  to  indicate  the  time 
Action  (or  Process,  decision,  etc.)  takes  up  without 
describing  the  Action's  nature. 


below  is 
a  certain 
further 


9.  DEBUGGING.  The  Primitive, 


TRACE 


is  not  used  to  represent  a  system’s  operations,  but  is  rather 
provided  as  a  convenience  to  the  user  in  the  task  of  tracing  a 
history  of  Process  execution  during  simulations  as  a  debugging 
facility. 


1.3. 2. 2  The  Resource  Entity  A  Resource  represents  a  component 
of  the  modeled  system  which  may  be  necessary  to  the  execution  of 
a  Process.  Typically,  a  Resource  will  be  required  for  more  than 
one  Process.  Where  several  Processes  demand  a  Resource  that  can 
serve  only  one  Process  at  a  time  all  but  one  will  stand  'n  a 
queue  until  the  Resource  is  available  for  them.  The  order  in 
which  the  Processes  will  make  use  of  the  contended  Resource  is  a 
function  of  the  priorities  that  have  been  assigned  to  the 
Processes  in  question  as  well  as  of  the  internal  structure  of  the 
Processes  as  defined  by  their  Primitives. 

1.3. 2. 3  The  Action  Ent i ty  The  Action  entity  is  used  to 
represent  any  action,  activity,  decision,  etc.  that  consumes 
time . 


1.3. 2. 4  The  Legal  Path  Table  The  Legs’  Path  Table  (LPT)  is  a 
set  of  routes  or  paths  between  nodes  in  the  system's  architec¬ 
ture.  The  LPT  is  selected  from  all  the  possible  paths  between 
the  nodes  along  the  links,  so  that  there  is  but  one  permissible 
routing  of  communication  between  the  various  nodes  in  the  archi¬ 
tecture.  The  LPT  is  accessed  by  several  other  elements  of  AISIM 
such  as  the  EVAL  Primitive,  the  keywords  $NODE ,  9NXTN0DE ,  and 
$LINK,  and  the  Message  Routing  Submodel  Processes. 
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1.3.2. 5  The  Queue  Entity  A  Queue  represents  any  holding  area, 
such  as  a  memory  buffer  or  job  queue,  for  elements  waiting  to 
take  up  their  role  in  the  operation  of  the  system.  User-defined 
Queues  can  be  used  as  a  holding  area  for  Items  as  well  as 
Resources.  A  user-defined  Queue  can  be  manipulated  in  a  number 
of  ways  described  later  and  in  the  AISIM  User's  Manual . 


1.3.3  ENTITIES  WHICH  SUPPORT  MATHEMATICAL  OPERATIONS 

1.3. 3.1  The  Constant  Entity  A  Constant  is  an  entity  whose  value 
does  not  change  during  a  simulation  run.  Constants  are  specified 
or  altered  in  the  DUI  and  can  be  edited  before  a  simulation  run 
in  the  AUI  but  cannot  be  changed  (and  do  not  change)  once  the 
execution  of  a  model  has  begun.  Several  parameters  required  in 
the  definition  of  an  AISIM  model,  (i.e.,  the  length  of  a  simula¬ 
tion  run,  the  number  of  Resource  units,  the  period  length  of  the 
simulation  and  the  sizes  of  Queue)  can  only  take  Constants  or 
simple  numerics  as  values. 

1.3. 3. 2  The  Variable  Entity  Variables,  by  contrast,  are  enti¬ 
ties  whose  values  can  change  during  the  exercise  of  a  model.  The 
majority  of  the  parameters  in  the  specification  of  a  model  can 
take  Variables  as  values. 

1.3. 3. 3  The  Table  Entity  Tables  are  single-value,  single¬ 
argument  functions  defined  by  the  user.  They  may  be  defined 
either  as  discrete,  continuous,  or  alphanumeric  and  may  have  from 
1  to  15  entries.  Tables  are  invoked  by  the  EVAL  Primitive  and 
serve  as  a  supplement  to  the  mathematical  operations  automati¬ 
cally  available  as  part  of  the  EVAL  primitive. 


2.  CREATING  SYSTEM  ARCHITECTURES 


With  the  basic  understanding  of  AISIM  modeling  concepts 
presented  in  the  previous  section.,  the  reader  should  now  be  able 
to  interact  with  the  DUI.  The  ex  .cises  here  are  intended  both 
to  deepen  the  user’s  grasp  of  AISIM  modeling  constructs  and  to 
familiarize  him  with  the  prompts  encountered  while  interacting 
with  the  computer.  In  general,  it  is  not  a  good  idea  to  begin 
the  design  of  an  AISIM  model  without  having  done  research  and 
preparation  on  paper  beforehand.  However,  as  a  teaching  device, 
we  shall  develop  fragments  of  an  architecture  from  requirements 
formulated  as  we  go  along. 

The  method  of  logging  on  is  computer-specific  so  we  shall  assume 
that  the  user  has  reached  the  point  at  which  the  computer  prompts 
him  with, 

READY 

which  indicates  that  one  is  logged  on.  To  obtain  access  to 
AISIM,  type, 

EXECUTE  AISIM  (cr) * 

You  will  be  offered  a  collection  of  information  that  looks  some¬ 
thing  like  that  depicted  in  Figure  1 


Thu  is  AISIM  PRODUCTION  VERSION  2.0,  which  was  built  fro» 
AISIM  VERSION  1 .1. 

2/5/82 

report  any  problem  to:  HERMAN  SCHULTZ  1-2308 

»»•  •  •• 


Figure  1.  Typical  Display  upon  Entering  the  AISIM  READY  Level, 
and  then  prompted  with, 

AISIM  READY 


0. 


•Hereafter , 


"(cr)"  will  indicate  a  carriage  return 


r 


To  enter  the  DUI,  type, 
d  p(test)  (cr) 

where  "test"  is  the  name  of  the  model  to  be  designed. 

The  user  will  be  prompted  with  information  that  looks  something 
like  that  shown  in  Figure  2. 


AISIM  R£ADV 

d  ptleit) 

CURRENT  PARAMETERS  IN  EFFECT: 

VERSION:  PRODUCTION 

PROJECT:  TEST 

USER:  TF01SQ8 

ENTER  r£$  TO  PROCEED,  NO  TO  ABORT... 


Figure  2.  Typical  Information  on  Entering  the  DUI 
By  typing, 

NO  (cr) 

one  will  return  to  the  AISIM  READY  level.  Typing, 

YES  (cr) 

will  put  one  in  the  DUI  sublevel  and  the  screen  will  display  a 
"*"  to  indicate  that  you  may  enter  DUI  commands. 

When  the  computer  displays  the  prompt  enter  the  Architecture 

Design  Editor  (ADE)  by  typing, 

ARCH  (cr) 

A  grid  like  that  in  Figure  3  will  appear  on  the  screen. 
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Figure  3.  Grid  on  Which  an  Architecture  is  Designed 

The  AISIM  constructs  manipulated  in  the  ADE  are  nodes  which 
represent  the  hardware  elements  of  a  system  and  links  which 
represent  lines  of  communication  between  them.  The  physical  lay¬ 
out  of  the  system  is  represented  by  picturing  nodes  and  links  on 
the  grid  to  represent  various  hardware  elements  of  a  system  and 
their  (possible)  lines  of  communication.  A  Resource  modeling 
entity  is  automatically  associated  with  each  node  or  link  when  it 
is  placed  in  the  architecture. 

As  a  mnemonic  aid  in  distinguishing  system  elements,  AISIM 
provides  fourteen  geometrical  symbols  for  nodes.  The  symbols  are 
called  by  the  three-letter  designations  given  in  Figure  4. 
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Figure  4.  Designations  of  the  Fourteen  Symbols 

With  two  exceptions  these  node  symbols  differ  from  one 
another  only  in  their  appearance.  The  two  exceptions  are  the 
so-called  "leaf-nodes"  tt£  and  lod.  These  nodes  may  be  connected 
to  the  modeled  architecture  by  only  one  link.  All  other  nodes 
may  be  connected  to  any  number  of  other  nodes  through  any  number 
of  links.  The  rationale  for  this  restriction  is  explained  in  the 
AISIM  User's  Manual ,  Section  6.3.3. 


2.1  DEFINING  ATTRIBUTES  FOR  SYMBOLS 

As  mentioned  earlier,  when  a  symbol  is  placed  in  the  architec¬ 
ture,  an  AISIM  entity  called  a  Resource  is  created  to  represent 
the  hardware  element  depicted  by  the  node  or  link.  Resources 
have  a  number  of  attributes;  some  are  named  system  attributes, 
others  are  user  named  and  defined  attributes.  The  DEFINE  SYMBOL 
command  allows  the  user  to  establish  attributes  to  be  associated 
with  each  symbol  type  so  that  when  placed  in  the  architecture, 
the  associated  Resource  will  be  created  with  all  attributes 
defined.  An  example  of  this  use  of  the  DEFINE  SYMBOL  command  is 
produced  by  typing: 


DEFINE  SQR  (cr) 


(SQR  could  be  replaced  with  any  of  the  14  symbol  mnemonics  or  the 
mnemonic  CON  if  a  link  is  being  defined.)  The  user  will  be 
prompted  by  a  form  as  shown  in  Figure  5. 


RESOURCE  NAME: 

TOTAL  NUMBER  OF  UNITS: 

INITIAL  NUMBER  OF  UNITS:  m 
ATTRIBUTES  PRESENT  (YES  OR  NO) 


cost:  mn 

DESCRIPTION: 


Figure  5.  First  Symbol  Definition  Form 

The  user  can  tab  or  space  through  this  form  using  the  tab  key  or 
space  bar  of  the  HP2647A  terminal.  Any  values  in  the  inverse 
video  fields  of  the  form  are  default  values  supplied  from  the 
AISIM  design  data  base.  The  user  may  change  these  fields  by 
positioning  the  cursor  as  described  above  and  then  typing  over 
the  existing  values.  The  form  with  the  new  values  can  be  entered 
into  the  data  base  by  striking  the  "ENTER"  key  of  the  HP2647A 
terminal.  The  user  will  then  be  given  another  form  as  shown  in 
Figure  6.  This  form  is  blank.  The  user  may  enter  up  to  fifteen 
attribute  names  and  related  values  of  his  choice  into  these 
fields.  For  example,  when  defining  attributes  of  a  symbol  type 
which  is  to  represent  a  disk  in  the  modeled  system,  the  attribute 
names  may  be  something  like  seek  time,  latency,  etc.,  and  the 
values  would  be  the  corresponding  values  for  the  particular  disk 
being  modeled. 


ATTRIBUTES 


NAME  VALUE 


Figure  6.  Second  Symbol  Definition  Form 

A  second  form  of  the  DEFINE  SYMBOL  command  takes  the  form: 

DEFINE  SYMBOL, RESOURCE  NAME  (cr) 

where  SYMBOL  is  one  of  the  symbol  mnemonics  or  CON  and  RESOURCE 
NAME  is  the  name  of  an  existing  Resource  entity.  This  command 
will  only  be  accepted  if  a  Resource  entity  has  been  previously 
defined  before  entering  the  ADE.  Since  the  user  has  not  defined 
any  Resource  entities  in  his  test  data  base  yet,  this  command 
would  fail.  The  trainee  might  want  to  try  this  command  later. 

If  a  named  Resource  entity  did  exist,  forms  similar  to  the  forms 
shown  above  would  be  displayed.  Instead  of  the  default  attri¬ 
butes  in  the  first  form  and  the  blank  second  form,  the  forms 
displayed  could  have  the  names  and  values  of  any  attributes  pre¬ 
viously  defined  by  the  Resource  entity  referenced  in  the  command. 


2.2  PLACING  NODES  ON  THE  GRID 


To  place  a  node  at  a  certain  location  on  the  grid — i.e.,  centered 
on  that  location — issue  a  command  designating  (1)  the  type  of 
node  to  be  placed,  (2)  a  user-given  name,  and  (3)  horizontal  and 
vertical  position  coordinates.  One  can  also  opt  to  indicate  the 
size  of  the  geometrical  shape  if  the  default  value,  equal  to  the 
number  of  characters  in  the  user-given  name,  is  unsuitable.  To 
center  a  square  named  N0DE1  twenty  units  from  the  left-hand  side 
and  thirty  units  from  the  bottom  in  Figure  4  above,  type, 

P  SQR,N0DE1, TO, 30  (cr) 
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Figure  7  shows  the  screen  display  that  would  result  from  this 
command. 
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Figure  7.  Architectural  Grid  With  a  Single  Node 

All  nodes  are  placed  in  this  way.  To  place  nodes  in  the  posi¬ 
tions  shown  in  Figure  8,  type  the  following  sequence  of  commands 

P  TTY, NODE 2 , 10,10  (cr) 

P  PRP,NODE3, 40, 30  (cr) 

P  TRI ,NODE4 , 85,10  (cr) 

P  TAP, NODE 5, 45,15  (cr) 

P  CRD,NODE6 ,80,35  (cr) 
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Figure  8.  Six  Nodes  on  an  Architectural  Grid 
2.3  CONNECTING  NODES 


The  second  step  in  creating  a  system  architecture  is  the 
placement  of  connections  between  the  nodes.  Such  connections,  or 
"links",  are  defined  by  specifying  (1)  the  node  from  which  the 
link  is  to  run,  (2)  the  node  t£  which  the  link  is  to  run,  and  (3) 
a  user-given  name  of  the  link.  To  place  a  link  called  "LINK1" 
from  NODE1  to  N0DE2,  type, 

CON  NODE 1 , NODE 2 , LINK1  (cr) 

This  command  places  a  cursor  at  N0DE1;  typing  any  character  other 
than  a  period  causes  a  straight  line  to  be  drawn  between  the 
centers  of  the  two  nodes,  thereby  drawing  the  link.  The  graphic 
result  is  shown  in  Figure  9. 
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Figure  9.  Architecture  with  One  Link  Defined 

Links  need  not  always  appear  as  straight  lines,  as  is  shown  in 
Figure  10. 
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Figure  10.  Architecture  with  a  Bent  Link 

To  create  links  that  bend,  do  not  hit  a  second  carriage  return 
after  the  graphics  cursor  is  displayed  (following  the  CON  com¬ 
mand)  .  Instead,  using  the  graphics  controls  on  the  HP2647A  ter¬ 
minal  (the  ones  shaped  like  arrow  heads,  not  the  ones  to  the  far 
right)  the  cursor  can  be  moved  to  the  spot  where  the  link  is  to 
bend.  When  the  cursor  is  at  the  point  of  the  bend,  type  in  a 
period  (.).  If  no  further  bending  is  desired,  typing  any  other 
non-period  character  will  complete  the  connection.  The  resulting 
connection  will  resemble  the  one  depicted  above  in  Figure  10. 

Links  may  be  given  more  than  one  bend  by  repeating  the  sequence 
of  moving  the  cursor  and  typing  a  period  (.),  and  then  depressing 
any  non-period  character  only  when  all  the  desired  bends  (up  to 
six)  have  been  created. 

To  create  the  links  shown  in  Figure  11,  type  the  following 
sequence  of  commands: 

CON  NODE1 ,N0DE4 , LINK 4  (cr) 

CON  NODE 3 , NODE6 , LINK3  (cr) 
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CON  NODE 3 , NODE 5 , LINK 5  (cr) 


Figure  11.  Architecture  with  Four  Links 

2.4  CHANGING  THE  SIZE,  TYPE ,  AND  NAME  OF  NODES  AND  LINKS 

The  size,  type,  or  name  of  nodes  and  the  names  of  links  can  be 
changed  using  the  CHANGE  command.  By  typing  the  following  com¬ 
mands,  nodes  and  links  may  be  altered: 

CHG  NAME, NODE 1,N0DEX  (cr) 

CHG  TYPE, NODE 2, LOD  (cr) 

CHG  SIZE,N0DE3, 7  (cr) 

CHG  NAME, LINK4, LINKZ  (cr) 

The  user  may  note  the  changes  on  his  screen.  By  typing  the  fol 
lowing  commands,  the  architecture  is  returned  to  its  original 
configuration: 


CHG  NAME , NODEX , NODE1  (cr) 

CHG  TYPE, NODE2, TTY  (cr) 

CHG  SIZE, NODE 3,5  (cr) 

CHG  NAME ,LINKZ ,LINK4  (cr) 

As  mentioned  earlier.  Resource  entities  are  created  by  the  AISIM 
system  to  model  the  architecture  elements.  When  the  name  or  type 
of  a  node  is  changed  or  the  name  of  a  link  is  changed,  the 
appropriate  changes  are  also  made  to  the  associated  Resource 
entities.  That  is,  when  a  node  ol  link  name  is  changed,  the 
associated  Resource  name  is  changed.  When  the  type  of  a  node  is 
changed,  new  attributes  may  replace  the  existing  attributes  of 
the  Resource  since  different  attributes  may  be  defined  for  the 
new  symbol  type.  Refer  to  Section  2.1  of  this  manual. 

2.5  DELETING  NODES  AND  LINKS 


Existing  nodes  and  links  may  be  deleted  from  a  system  architec¬ 
ture  with  the  DELETE  command.  For  this  example,  to  eliminate  the 
connection  between  N0DE1  and  N0DE2  type, 

DELETE  LINK1  (cr) 

The  result  at  the  screen  would  be  that  the  link  named  "LINK1" 
would  disappear. 

When  a  node  is  deleted,  all  of  the  links  associated  with  it 
also  disappear.  As  an  example  type, 

DELETE  N0DE6  (cr) 

The  result  of  deleting  LINK1  and  N0DE6  is  shown  in  Figure  12. 

Note  that  LINK3  disappeared  also. 
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Figure  12.  The  Result  of  Deleting  LINK1  and  N0DE6 


2.6  MOVING  PREVIOUSLY  PLACED  NODES 


The  location  of  a  node  on  the  architecture  grid  may  be  changed 
with  the  MOVE  command.  For  example,  to  move  NODE4 ,  from  its 
current  position  to  the  coordinates  55,5  one  issues  the  command: 

MOVE  N0DE4 , 55 , 5  (cr) 

The  graphic  result  is  shown  in  Figure  13.  The  symbol  is  now  cen¬ 
tered  at  55,5  with  all  of  its  previously  defined  connections 
intact. 
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Figure  13.  The  Result  of  Moving  N0DE4 


2.7  RECONNECTING  EXISTING  LINKS 


The  previous  example  of  moving  N0DE4  created  a  problem  that  can 
be  solved  with  the  command  RECONNECT.  As  Figure  13  shows,  the 
link  between  N0DE1  and  N0DE4  now  runs  through  NODES.  The  connec¬ 
tion  can  be  made  to  bend  around  N0DE5  by  first  typing, 

RECON  LINK4  (cr) 

This  command  will  delete  the  existing  graphics  for  the  link 
between  N0DE1  and  N0DE4  and,  as  in  the  original  CONNECT  command, 
place  the  cursor  (+)  at  N0DE1 .  Using  the  sequence  of  cursor 
movements  and  periods  (.)  described  in  Section  2.3,  up  to  six 
bends  in  the  existing  connection  between  NODE1  and  N0DE4  can  be 
created.  To  complete  the  connection,  type  any  non-period 
character.  The  graphic  result  will  be  something  like  that  shown 
in  Figure  14. 
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Figure  14.  Architecture  After  Reconnecting 
2.8  ALTERING  ONE'S  VIEW  OF  THE  ARCHITECTURE  GRID 


The  usable  grid  space  in  ADE  is  actually  four  times  what  can 
be  displayed  on  the  terminal  screen  at  one  time.  If  an  architec¬ 
tural  design  is  too  large  for  the  screen  to  accommodate,  dif¬ 
ferent  parts  of  the  total  workspace  can  be  viewed  and  manipulated 
through  the  WINDOW  command.  The  WINDOW  command  allows  the  direc¬ 
tional  change  of  the  user's  view  of  the  grid.  The  command  speci¬ 
fies  the  direction  of  change--up,  down,  right  or  left — as  well  as 
the  number  of  grid  units  the  view  is  to  be  changed. 

For  example,  to  move  the  view  of  the  screen  in  Figure  14 
down  15  units,  type, 

WINDOW  D, 15  (cr) 

Figure  15  shows  the  result  of  this  command. 
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Figure  15.  Result  of  WINDOW  Command 

The  WINDOW  command  will  accomplish  both  horizontal  and 
vertical  movements  at  the  same  time.  To  move  our  view  of  the 
screen  further  down  15  units  and  20  units  to  the  right,  type, 

WINDOW  D, 1 5 , R, 20  (cr) 

Figure  16  shows  the  result  of  this  command. 
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Figure  16.  The  Result  of  Further  Use  of  WINDOW 

Note  that  the  WINDOW  command  parameters  required  to  get  back 
to  the  original  (HOME)  position  are  always  displayed  above  the 
upper  right  corner  of  the  architecture  grid. 


2.9  DEFINING  LEGAL  PATHS 


The  purpose  of  the  Architecture  facility  is  to  specify 
routes  of  communication  between  hardware  elements  so  that  Process 
execution  will  be  realistically  related  to  the  physical  layout  of 
a  system.  Such  routes  are  represented  by  a  Legal  Path  Table 
which  specifies  the  links  and  the  nodes  through  which  communica¬ 
tion  from  one  node  to  another  must  take  place.  There  are  several 
methods  of  defining  a  Legal  Path  Table  (LPT).  Three  methods  are 
offered  to  the  user  at  the  end  of  an  ADE  session.  These  methods 
are  predefined  algorithms  for  the  definition  of  an  LPT  which  can 
be  executed  optionally  at  the  user's  discretion.  See  the  AISIM 
User's  Manual  for  details  of  how  these  algorithms  function.  For 
many  architectures  it  is  more  economical  to  create  the  Legal  Path 
Table  while  defining  the  configuration  of  hardware  elements 


Page  23 


rather  than  using  the  algorithms  mentioned  above.  If  an  LPT  is 
generated  according  to  the  following  discussion,  the  predefined 
algorithms  should  be  bypassed  since  they  would  erase  the  LPT  so 
defined. 

Suppose  we  augment  the  architecture  developed  above  with  more 
links  so  that  it  resembles  that  shown  in  Figure  17. 
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Figure  17.  Augmented  Architecture 

The  LPT  is  defined  by  means  of  the  command  DEFINE  PATH.  If,  for 
example,  NODE1  is  to  communicate  with  N0DE4  along  the  communica¬ 
tion  lines  represented  by  the  links  LINK3 ,  LINK5 ,  and  LINK2 , 
type, 

DEFINE  PATH, NODE 1 ,NODE4,LINK3,LINK5,LINK2  (cr) 

No  confirmation  will  be  displayed  immediately  at  the  screen,  but 
the  Legal  Path  Table  will  have  been  augmented  to  reflect  the  new 
paths.  However,  the  command  LIST  PATH  enables  the  user  to 
inspect  the  Legal  Path  definitions  currently  in  effect.  To 
obtain  a  listing  at  the  screen  of  the  Legal  Path  from  N0DE1  to 
N0DE4 ,  type. 
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LIST  PATH,N0DE1,N0DE4  (cr) 

The  resulting  list  is  shown  in  the  upper  right-hand  corner  of 
Figure  18. 


Figure  18.  Typical  List  of  Legal  Paths  Obtained  in  ADE 


Note  that  paths  from  N0DE3  and  NODES  to  N0DE4  have  been  automati 
cally  defined  by  the  preceding  DEFINE  PATH  command.  The  princi¬ 
ple  is  that  any  time  a  Legal  Path  is  defined  through  a  number  of 
nodes,  the  AISIM  system  creates  Legal  Paths  from  all  nodes 
through  which  the  path  passes  to  the  destination  t£  node.  Care 
should  be  taken  in  defining  subsequent  Legal  Paths  according  to 
this  method.  Any  conflicts  of  path  routing  in  paths  defined 
later  would  result  in  the  elimination  of  previously  defined 
paths.  Following  is  an  illustration  of  this  operation  of  the 
system.  Assume  that  the  path  has  been  created  as  above.  If  the 
user  should  now  enter  the  command: 

DEFINE  PATH, NODE 2, NODE 4, LINK1 , LINK 4  (cr) 
not  only  would  the  path  from  N0DE2  to  N0DE4  be  established,  but 
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the  path  from  NODE 1  t£  NODE4  would  be  altered  to  be  the  direct 
path  via  LINK4.  The  paths  defined  automatically  from  the  previ¬ 
ous  command  (i.e.,  the  paths  from  nodes  N0DE3  and  NODE5  to  NODE4 ) 
would  still  exist  since  there  was  no  conflict  with  these  paths 
and  the  newly  defined  path. 
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3.  DEFINING  PROCESSES  IN  THE  DUI 


Whereas  the  Architecture  Design  Editor  (ADE)  is  used  to 
represent  the  the  physical  layout  of  a  system,  the  Process  Editor 
Interface  (PEI)  is  used  to  represent  the  logic  and  data-handl ing 
behavior  of  processes  in  the  system. 

This  section  provides  examples  to  familiarize  the  user  with 
the  commands  and  prompts  used  in  AISIM.  Earlier  the  user  was 
urged  to  begin  the  design  of  an  AISIM  model  with  sufficient 
research  and  planning  to  fully  understand  the  system  to  be 
modeled.  However,  as  a  teaching  device,  we  shall  develop  frag¬ 
ments  of  a  Process  from  requirements  formulated  as  we  go  along. 

The  exercises  here  are  intended  both  to  deepen  the  user's  grasp 
of  the  Process  Primitives  and  to  familiarize  him  with  the  prompts 
encountered  while  interacting  with  the  computer. 

Assuming  the  trainee  has  just  completed  the  foregoing  section, 
entered  an  END  command  to  exit  the  ADE  sublevel,  and  another  END 
command  to  bypass  the  LPT  generation,  he  will  be  at  the  DUI  level 
of  operation.  A  should  be  displayed.  To  invoke  the  PEI  sub- 

level  of  the  DUI,  one  enters  the  EDIT  PROCESS  command  designating 
the  name  of  the  Process  to  be  edited.  Once  in  the  PEI,  the  user 
can  terminate  the  PEI  session  by  entering  an  END  command. 

Consider  first  the  simplest  Process  that  could  be  of  any  use 
to  the  modeler  of  a  system:  the  Process  starts,  a  certain  amount 
of  time  is  taken  with  an  Action  and  then  the  Process  ends.  This 
Process  will  be  represented  in  AISIM  by  the  START  symbol,  the 
ACTION  Primitive  and  the  END  symbol.  To  represent  such  a  Process 
in  AISIM,  one  begins  by  issuing  the  command, 

EDIT  PROCESS, EXAMPLE, NEW  (cr) 

which  informs  the  computer  that  one  wishes  to  design  a  Process 
named  "EXAMPLE"  which  has  not  yet  been  defined*.  The  computer 
will  respond  with  a  form  to  be  filled  in  at  the  terminal.  This 
is  done  by  typing  into  the  fields  provided  in  the  form.  The  form 
is  shown  in  Figure  19. 


0. 


*To  alter  a  Process  that  has  been  previously  defined,  one 
would  not  enter  the  "NEW"  part  of  the  command. 
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STMT 


PROCESS  NAME  mgi  H0D£  ■ 
ATTRIBUTES  An  ACHES  (YES  OR  HO) 


PROCESS  DESCRIPTION 


STMT  BLOCK  nPE 


ENTER  *PARH*  FOR  PARAMETER  PASSING 
ENTER  •ITEM"  FOR  ITEM  PASSING 
ENTER  *STD  "  FOR  STANDARD  PROCESS 


Figure  19.  Initial  Form  for  Process 

The  NODE  field  asks  for  the  node  in  the  architecture  with 
which  the  Process  is  associated.  Since  this  Process  is  not  yet 
related  to  an  architecture,  the  field  is  left  blank.  The  next 
field  allows  the  assignment  of  attributes  to  the  Process.  For 
the  present,  we  shall  decline  to  do  so.  The  field  labeled  PRO¬ 
CESS  DESCRIPTION  allows  the  user  to  describe  the  Process.  In 
this  case,  type  "EXAMPLE  PROCESS". 

Depress  the  ENTER  key  (located  above  the  keyboard  proper). 
The  cursor  will  sweep  along  the  fields,  the  screen  will  go  blank 
for  a  moment  and  then  display  the  image  depicted  in  Figure  20. 
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Figure  20.  Graphic  Display  That  Follows  Entering  a  Process 
of  the  Standard  Kind 

Much  of  the  information  you  entered  on  the  form  now  appears  in 
this  graphic  representation  of  EXAMPLE.  (The  "NO"  to  the  right 
of  the  START  symbol  indicates  the  the  Process  has  no  attached 
attributes) . 

To  place  an  ACTION  Primitive  between  the  Start  and  the  End  sym¬ 
bols,  enter  the  command, 

P  ACTION  (cr) 

which  tells  the  computer  to  place  an  ACTION  Primitive  between  the 
last  Primitive  defined  and  the  End  symbol.  The  computer  will  now 
display  a  new  form  to  be  filled  in.  This  is  shown  in  Figure  21. 


PARAWTERS  FOR  ACTION: 

ACTION  HAW:  NT  HOD:  | 

WAN  TIW:  ■■■  DClTA-TIW: 
COHWNT:  ■■■■■■■ 

% 


Figure  21.  Form  for  the  ACTION  Primitive 
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The  field  ACTION  NAME  requests  a  name  for  the  Primitive  in 
the  Process,  which  should  be  identical  with  the  name  of  the  asso¬ 
ciated  Action  entity  (Action  entities  are  described  in  section 
4.1).  We  shall  call  it  "Delay".  The  field  COMMENT  is  a  place  to 
write  a  short  reminder  of  what  the  ACTION  Primitive  is  supposed 
to  represent.  The  three  remaining  fields  METHOD,  MEAN  TIME,  and 
DELTA-TIME  enable  the  user  to  vary  the  time  taken  up  by  the 
ACTION  by  invoking  various  statistical  distribution  methods  (such 
as  exponent,  uniform,  etc.  See  section  3.9.1  of  the  AISIM  User's 
Manual  for  a  description  of  the  valid  distributions.)  Assume  that 
the  ACTION  always  requires  the  same  amount  of  time,  and  hence  the 
MEAN  TIME  requested  will  be  equal  to  the  duration  of  the  ACTION. 
Indicate  the  time  with  a  variable  whose  value  for  this  example  is 
specified  elsewhere,  calling  it  "Tl". 

The  form  should  then  be  filled  in  thus:  call  the  ACTION  "Delay", 
set  the  method  at  "uniform",  and  set  the  MEAN  TIME  at  "Tl".  Type 
the  comment  field  "Action  which  causes  delay".  Leave  the  field 
labeled  DELTA  blank.  After  pressing  the  "ENTER"  key  the  screen 
will  display  a  new  version  of  EXAMPLE,  as  depicted  in  Figure  22. 


Figure  22.  Process  with  a  Single  ACTION 

3.1  HOLD 


EXAMPLE  may  be  augmented  in  a  number  of  ways.  For  example,  the 
ACTION  Delay  may  be  repeated  in  succession.  There  are  two  ways 
to  repeat  this  ACTION  in  a  revised  version  of  EXAMPLE.  First, 
one  can  place  more  copies  of  Delay  in  the  Process,  one  after 
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another,  with  the  command 

P  ACTION  (cr) 

This  command  may  be  repeated  as  many  times  as  one  wishes  the 
Action  to  be  performed  in  the  Process.  The  second  method  of 
creating  several  instances  of  an  ACTION,  which  is  less  time- 
consuming,  involves  the  HOLD  storage  area.  HOLD  constitutes  a 
storage  area  for  Primitives  that  are  likely  to  be  used  more  than 
once  with  little  or  no  alteration.  To  place  a  previously  defined 
Primitive  into  HOLD,  type 

HOLD  2  (cr) 

The  number  2  represents  the  position  of  the  Primitive  in  the  Pro¬ 
cess  to  be  stored  in  HOLD.  The  position  is  indicated  by  the 
numbers  in  the  column  on  the  left.  Hereafter,  the  ACTION  Primi¬ 
tive  "Delay"  may  be  placed  in  a  Process  by  typing, 

P  HOLD  (cr) 

Each  time  this  latter  command  is  issued,  the  user  will  be 
presented  with  the  form  associated  with  the  Primitive  in  case  any 
small  alterations  in  its  parameters  are  to  be  made.  Whether  or 
not  any  alterations  are  made,  pressing  the  ENTER  key  will  result 
in  the  placement  of  the  Primitive  stored  in  HOLD  in  the  Process 
being  edited. 

Figure  23  shows  the  display  that  will  appear  after  several 
identical  ACTION  Primitives  have  been  redefined  in  succession  or 
after  the  HOLD  storage  area  containing  the  ACTION  "Delay"  has 
been  placed.  The  procedure  of  repetition  will  occur  as  many 
times  as  the  user  requests  it. 
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Figure  23.  Process  with  Three  Identical  ACTION  Primitives 
3.2  ENTRY  AND  LOOP 

If  the  ACTION  "Delay"  is  to  be  performed  a  certain  n  number 
of  times,  as  in  the  most  recent  version  of  EXAMPLE,  a  much 
simpler  procedure  is  available  than  that  of  placing  n  instances 
of  the  ACTION  between  the  START  and  END  symbols.  One  can  instead 
indicate  more  directly  that  a  certain  part  of  a  Process  is  to 
repeat  itself  an  number  of  times.  This  is  accomplished  by 
means  of  the  Primitives  LOOP  and  ENTRY.  Figure  24  shows  EXAMPLE 
altered  with  LOOP  and  ENTRY  Primitives  to  cause  a  triple  repeti¬ 
tion  of  the  ACTION  "Delay". 
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Figure  24.  Process  with  Triple  Repetition  of  the  ACTION  Delay 

The  diamond-shaped  figure  indicates  that  the  line  of  processing 
is  to  be  diverted  to  the  point  labled  "RETURN"  above  it  (it  could 
have  been  given  any  label  whatever  up  to  8  characters) . 

To  effect  the  LOOP  Primitive  as  shown  in  Figure  24,  we  must  first 
get  rid  of  the  two  extra  ACTION  Primitives.  This  is  done  by  typ¬ 
ing  the  following  commands: 

DELETE  3  (cr) 

DELETE  3  (cr) 

P  LOOP  (cr) 

The  screen  will  show  the  form  shown  in  figure  25: 

PARAHETEBS  FOR  LOOP: 

LOOP  TO  LABEL: 

LOOP  ■■■  TinES 

CQWEMT:  ■■■■■■■■■■ 

% 

Figure  25.  Form  for  the  LOOP  Primitive 
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The  first  field  asks  for  the  name  of  the  entry  point  to  which 
Process  control  is  to  be  diverted.  The  second  asks  for  the 
number  of  times  control  is  to  be  diverted.  The  remaining  two 
f i elds  are  sel f-expl an? to ry . 

The  ENTRY  Primitive  must  now  be  placed  above  the  ACTION  Primi¬ 
tive.  Since  the  PLACE  (or  "P")  command  by  default  inserts  the 
new  Primitive  just  before  the  End  symbol,  a  modified  PLACE  com¬ 
mand  is  required  to  place  a  Primitive  elsewhere  in  the  sequence. 
To  use  this  command,  type, 

P  ENTRY, 2  (cr) 

The  number  "2"  indicates  where  the  Primitive  is  to  be  placed, 
referenced  by  the  column  of  numbers  on  the  left  of  the  Process 
d iag  ram . 

The  screen  will  then  display  the  form  shown  in  Figure  26. 

parameters  tor  entry-. 

ENTRY  LABEL:  m 
COMMENT: 

s 

Figure  26.  Form  for  the  ENTRY  Primitive 

The  label  will,  in  this  case,  be  determined  by  the  LOOP  label 
previously  defined.  The  ENTRY  LABEL  field  should  be  entered 
exactly  as  in  the  LOOP  LABEL,  i.e.,  as  "RETURN".  Type  an 
appropriate  comment  in  the  field  provided,  such  as,  "ENTRY  FROM 
LOOP  BELOW".  The  result  should  be  as  in  Figure  24. 

3. 3  PROB,  TEST,  COMPARE  AND  BRANCH 

Four  other  Primitives,  PROB,  COMPARE,  BRANCH,  and  TEST  are  simi¬ 
lar  to  LOOP  in  that  they  represent  a  branching  to  an  ENTRY  Primi 
tive.  EXAMPLE  may  be  altered  in  the  following  four  ways. 

3.3.1  PROB  The  PROB  Primitive  is  used  to  indicate,  for  example 
that  the  re-execution  of  the  ACTION  "Delay"  has  only  a  certain 
degree  of  probability. 

Since  AISIM  has  no  command  for  directly  replacing  one  Primitive 
with  another,  the  existing  Primitive  LOOP  must  first  be  deleted. 

Enter  the  command, 

DEL  4  (cr) 

where,  as  before,  "4"  indicates  the  location  of  the  Primitive  to 
be  deleted.  Figure  27  shows  the  display  produced  when  the  LOOP 
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Primitive  is  deleted. 


cmwa  p«occ:: 


Figure  27.  EXAMPLE  after  Deletion  of  LOOP  Primitive 

The  PLACE  command  is  used  to  insert  a  PROB  Primitive  between 
the  ACTION  "Delay"  and  the  END  symbol.  Type, 

P  PROB  (cr) 

The  screen  will  offer  the  form  shown  in  Figure  28. 


PARAMETERS  FOR  PROBABILISTIC  BRANCH: 
BRANCH  TO  LABEL:  ■■) 
PROBABILITY  OF  BRANCH:  ■■£ 
CONTENT:  ■■■■■Hi 

% 


Figure  28.  Form  for  PROB  Primitive 

Complete  the  first  field  with  RETURN.  The  second  field  should  be 
filled  in  with  the  probability  of  branching,  given  in  percen¬ 
tages.  Suppose  here  a  25%  chance  of  branching.  Type  the 
appropriate  comment,  "25%  chance  of  branching".  The  resulting 
display  diagram  is  given  in  Figure  29. 
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Figure  29.  Process  with  Probabilistic  Branch 

3.3.2  TEST  Another  kind  of  branching  Primitive  is  TEST.  As 
mentioned  earlier.  Processes  often  make  use  of  Resources  for 
which  there  is  competition.  The  TEST  Primitive  represents  the 
procedure  of  ascertaining  the  availability  of  a  given  Resource 
and  branching  if  that  Resource  is  not  available,  or  continuing  if 
it  is.  This  Primitive  does  not  automatically  allocate  the 
Resource.  To  place  the  TEST  Primitive  (after  having  deleted  the 
PROB  Primitive  from  the  latest  version  of  EXAMPLE),  type, 

P  TEST  (cr) 

The  screen  will  display  the  form  shown  in  Figure  30. 

PAHAMCTERS  fOR  TEST; 

RESOURCE  NAME: 

BRANCH  TO  LABEL  H  If  NOT  AVAILABLE 
COMMENT: 

% 

Figure  30.  Form  for  TEST  Primitive 

In  the  RESOURCE  NAME  field  type  the  name  of  the  Resource  whose 
status  is  to  be  ascertained.  The  LABEL  and  COMMENT  are  self- 
explanatory.  If  the  PROB  Primitive  in  the  p.  ious  version  of 
EXAMPLE  is  replaced  by  TEST  (as  in  this  example),  EXAMPLE  will 
now  appear  as  in  Figure  31. 


E*flHPl£  PROCESS 


■  START 


Page  36 


EXPPPU  ppocess 


•I 


« 


m 


*1 


« 


/ START  \ 

V  EXPHPLE  /  HO 


ENffy  no*  loop  mo* 


acnw  hhich  c ousts  kip* 


Figure  31.  Process  with  TEST  Branching 

3.3.3  COMPARE  In  addition  to  probabilistic  branching,  AISIM 
also  allows  for  conditional  branching  less  specialized  than  th 
TEST  Primitive.  Most  of  these  branchings  will  require  the  COM 
PARE  Primitive.  The  COMPARE  Primitive  compares  two  numerical 
values  with  respect  to  some  relation  and  branches  to  a  named 
ENTRY  Primitive  if  the  relation  holds. 

To  place  the  COMPARE  Primitive,  delete  the  previously  defined 
TEST  Primitive  and  type, 

P  COMPARE  (cr) 

The  screen  will  display  the  form  depicted  in  Figure  32. 
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PARAMETERS  for  compare 


IF  OPERAND  1  :m  QUALIFIER  1  :| 
RELATION 

OPERAND  QUALIFIER  2:| 

BRANCH  TO:BHB 


COMMENT  :■■■■■■■■■■■ 

4 

Figure  32.  Form  for  COMPARE  Primitive 

The  fields  OPERAND  1  and  OPERAND  2  hold  the  variables  whose 
values  are  to  be  compared.  The  values  may  be  represented  by 
arbitrarily  chosen  names  of  variables  (such  as  VAR1  and  VAR2) . 
They  are  compared  with  respect  to  the  following  six  arithmetical 
relations  indicated  by  the  two  letter  code: 


EQ 

for 

NE 

for 

GT 

for 

LT 

for 

GE 

for 

LE 

for 

"equal  to" 

"not  equal  to" 

"greater  than" 

"less  than" 

"greater  than  or  equal  to" 
"less  than  or  equal  to" 


The  BRANCH  TO  and  COMMENT  labels  are  now  self-explanatory.  The 
two  QUALIFIER  fields  serve  several  purposes,  the  most  important 
of  which  is  to  allow  the  comparison  of  attributes  of  entities  as 
opposed  to  simple  variables  or  numerics.  The  user  should  for  the 
present  disregard  the  complication  posed  by  these  fields  and 
leave  them  empty.  Fill  in  the  OPERAND  fields  with  arbitrarily 
chosen  names  of  variables,  "VAR1"  and  "VAR2" .  If  the  TEST  Primi¬ 
tive  is  replaced  by  the  COMPARE  Primitive  with  the  foregoing 
information  entered  on  its  form,  the  new  version  of  EXAMPLE  will 
be  as  displayed  in  Figure  33. 
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Figure  33.  Process  with  COMPARE  Primitive 

And  thus  EXAMPLE  is  set  to  return  control  to  the  Entry  Primitive 
if  the  value  assigned  to  the  variable  VAR1  is  less  than  the  value 
assigned  to  the  variable  VAR2.  These  assignments  are  presumed  to 
be  made  elsewhere. 


3.4  VARIABLE  MANIPULATION 

In  the  previous  example  of  the  COMPARE  Primitive,  note  that  if 
the  condition  solicited  is  true,  i.e.,  if  VAR1  was  less  than 
VAR2 ,  EXAMPLE  would  perform  the  ACTION  "Delay"  indefinitely.  On 
each  occasion  in  which  the  comparison  is  made,  the  relation  will 
hold  and  hence  the  Process  will  always  be  instructed  to  branch  to 
RETURN.  If  neither  variable  changes  its  value,  the  Process  will 
continue  until  it  is  halted  by  other  causes  (such  as  having  a 
Resource  necessary  to  it  allocated  elsewhere) . 

Using  two  new  Primitives,  ASSIGN  and  EVAL,  we  can  alter  EXAM¬ 
PLE  so  that  the  ACTION  "Delay"  does  not  go  on  forever  but  only 
for  a  certain  maximum  time  ("Maxtime").  This  is  accomplished 
with  the  ASSIGN  Primitive  which  introduces  a  new  variable  for  the 
accumulation  of  time  consumed  by  the  ACTION'S  execution  times  and 
by  the  EVAL  Primitive,  which  recalculates  the  value  of  this  accu¬ 
mulated  time  each  time  the  ACTION  is  performed. 
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First,  to  command  the  computer  to  place  an  ASSIGN  Primitive 
between  the  START  and  the  ENTRY,  type, 


P  ASSIGN, 2  (cr) 

The  screen  will  now  show  the  form  displayed  in  Figure  34: 

PARAMETERS  FOR  ASSIGN 


Figure  34.  Form  for  ASSIGN  Primitive 

For  this  example  disregard  the  fields  labeled  Q1  and  Q 2;  they 
serve  the  same  purpose  as  do  the  QUALIFIER  fields  in  the  COMPARE 
Primitive.  The  purpose  of  this  exercise  is  to  create  a  tem¬ 
porarily  useful,  local  variable,  which  we  shall  call  "acctime" 
whose  value  represents  the  amount  of  time  that  has  been  consumed 
in  the  repeated  execution  of  "Delay”.  At  the  beginning  of  the 
Process  the  initial  value  of  the  variable  will  be  zero.  Hence, 
complete  the  Vl  field  with  "ACCTIME"  and  the  V2  field  with  "0". 
When  this  information  is  entered,  the  screen  will  display  the 
graphic  representation  shown  in  Figure  35. 
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Figure  35.  Process  with  Primitives  ASSIGN,  ACTION,  and  COMPARE 

To  provide  an  apparatus  Cor  updating  the  variable  "acctime"  on 
each  occasion  of  the  ACTION’S  execution,  an  EVAL  Primitive  must 
be  placed  between  the  ACTION  and  COMPARE  Primitives.  To  do  this, 
type, 

P  EVAL , 5  (cr) 

The  screen  will  display  the  form  shown  in  Figure  36. 

parameters  for  evaluate 

SET  VARIABLE FUNCT!OM:^gg| 

QPERAHDli^m  QPERAND2  :^| 

COMMENT 

S 

Figure  36.  Form  for  EVAL  Primitive 

The  SET  VARIABLE  field  holds  the  name  of  the  variable  whose  value 
is  to  be  calculated.  The  FUNCTION  field  contains  the  name  of  the 
operation  to  be  performed  on  the  two  operands  contained  in  the 
fields  0PERAND1  and  0PERAND2.  A  large  variety  of  functional 
operations  are  available  for  this  field  (see  AISIM  User's  Manual , 
section  3.9.11  for  a  list).  For  this  example,  the  SET  VARIABLE 
field  should  be  "acctime";  the  Function,  "add";  OPERANDl ,  "tl" 
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and  0PERAND2  "acctime".  Type  an  appropriate  comment,  such  as 
"evaluating  acctime".  The  graphic  representation  of  EXAMPLE  will 
be : 


I  |  cxm»u  noun 


START 


Figure  37.  Process  with  ASSIGN,  ACTION,  COMPARE,  and  EVAL 

This  Primitive  instructs  the  computer  to  add  the  current  value  of 
the  variable  "Tl"  to  the  value  of  "ACCTIME",  producing  an  updated 
figure  for  the  total  time  consumed  by  "Delay".  Type  an  appropri¬ 
ate  comment  such  as,  "updating  accumulated  time". 

The*  Process  still  requires  alteration.  The  variables  presently  in 
the  COMPARE  Primitive  must  be  changed  from  VAR1  and  VAR2 ,  respec¬ 
tively,  to  "acctime"  and  "maxtime".  To  do  this,  we  must  edit  the 
COMPARE  Primitive  by  typing, 

C  6  (cr) 

This  command  tells  the  computer  that  you  wish  to  alter  one  or 
more  of  the  previously  defined  parameters  in  the  Primitive  at 
location  6.  The  screen  will  display  the  form  for  the  Primitive. 
It  can  be  altered  simply  by  writing  over  the  existing  informa¬ 
tion.  When  this  is  done  and  the  form  is  "entered",  EXAMPLE  will 
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satisfy  the  specifications  for  its  alteration.  Its  graphic 
representation  will  be  as  in  Figure  38. 
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Figure  38.  Process  with  Comparative  Branching 
3.5  ITEM  MANIPULATION 


Another  group  of  Primitives  is  categorized  under  the  headings 
Queue  Handling  and  Item  Handling.  These  include  CREATE,  DESTROY, 
FILE,  FIND  and  REMOVE.  The  Primitives  CREATE  and  FILE  will  be 
used  in  this  example.* 

Consider  the  first  version  of  EXAMPLE  which  consisted  of  the 
single  ACTION  Primitive  "Delay".  Suppose  now  that  we  conceive  of 
EXAMPLE  as  one  which  gives  rise  to  new  data  elements — messages, 
information,  potential  communications.  This  function  of  the  Pro¬ 
cess  may  be  represented  by  means  of  the  CREATE  Primitive,  which 
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*  Consult  the  AISIM  User's  Manual  for  information  on  the 
Primitives  DESTROY,  FIND  and  REMOVE 
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represents  the  introduction  of  Items--one  of  the  AISIM  modeling 
entities  that  represent  transient  data  elements--into  the  modeled 
system.  To  place  the  Primitive  CREATE  below  the  ACTION  Delay  in 
EXAMPLE  type, 

P  CREATE  (cr) 

The  form  for  CREATE  is  shown  in  Figure  39. 

parameters  for  create 
ITEMS  TQ  BE  CREATED  ARE: 


CQfWENT: 


Figure  39.  Form  for  CREATE  Primitive 

Complete  this  form  with  the  names  of  the  Items  to  be  created. 
Enter  the  Item  name  "MSG"  and  an  appropriate  comment,  "TRANSIENT 
DATA  ELEMENT".  EXAMPLE  will  now  appear  as  indicated  in  Figure 
40. 
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Figure  40.  Item  Creating  Process 


Items--trans ient  data  elements — can  also  be 
areas  called  Queues  with  the  FILE  Primitive.  To 
Primitive  below  the  CREATE  Primitive  in  EXAMPLE, 


filed  in  holding 
place  a  FILE 
type, 
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P  FILE  (cr) 


The  form  for  File  is  as  shown  in  Figure  41. 

PARAHCTE8S  FOR  FILE: 


Figure  41.  Form  for  FILE  Primitive 

Complete  the  field  FILE  ITEM  NAME  with  Hmsg".  The  OPTION  field 
tells  where  in  the  Queue  the  Item  is  to  be  placed.  This  location 
is  specified  relative  either  to  absolute  locations  on  the  Queue 
("FIRST"  and  "LAST")  or  relative  to  some  other  Item  already  on 
the  Queue  ("BEFORE"  and  "NEXT")*.  The  OPTION  field  will  have  as 
a  default  parameter  LAST.  In  the  ON  QUEUE  field  enter  MSG-QUE. 
The  graphic  representation  of  this  Process  is  indicated  in  Figure 
42. 


Figure  42.  Process  which  Creates  and  Files  Message  Items 


0. 


*The  method  by  which  the  system  identifies  the  Item  relative 
to  which  other  Item  is  to  be  placed  on  a  Queue  (with  the 
OPTION  BEFORE  or  NEXT)  need  not  concern  us  here.  For  more  on 
this,  see  AISIM  User's  Manual ,  Section  3.9.12. 
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3.6  RELATIONS  AMONG  PROCESSES 


This  section  deals  with  the  relationships  that  the  execution  of 
Processes  bear  to  one  another  in  an  AISIM  Model,  and  how  one  Pro¬ 
cess,  and  its  execution,  affects  the  execution  of  another. 
Processes  affect  one  another's  execution  in  three  ways: 

1.  by  sending  Items  that  trigger  the  execution  of  another  Pro¬ 
cess  . 

2.  by  triggering  the  execution  of  another  Process  through  a 
CALL  Primitive  where  the  CALL  may  or  may  not  pass 
parameters. 

3.  by  competing  for  and  obtaining  use  of  a  Resource  needed  by 
another  Process. 

To  understand  how  parameter  and  Item  "passing"  affect  the  execu¬ 
tion  of  a  Process,  consider  the  form  completed  in  the  first  ver¬ 
sion  of  EXAMPLE.  In  the  form  presented  as  a  result  of  the  com¬ 
mand  to  edit  a  Process  (i.e.,  E  PROCESS , EXAMPLE , NEW) ,  in  the 
START  field  TYPE,  the  choices  included  "STD",  "PARM"  and  "ITEM", 
standing  for,  respectively,  "standard"  "parameter  passing"  and 
"Item  passing".  These  options  are  distinguished  from  one  another 
in  the  following  way.  A  Process  can,  before  it  is  fully 
designed,  be  thought  of  as  a  "black  box"  whose  internal  workings 
are  unknown.  If  the  Process  is  conceived  to  be  one  that  performs 
its  function  without  having  to  be  given  anything  in  the  way  of 
information  or  data  elements  it  will  be  a  Standard  Process.  If 
the  Process  requires  certain  data  elements — discrete,  countable 
entities — in  order  to  execute,  then  it  is  an  "Item  passing"  Pro¬ 
cess.  Finally,  if  the  Process  uses  values  of  variables  local  to 
another  Process,  it  is  a  Parameter  passing  Process. 

For  the  first  example,  consider  Item  Passing  Processes.  In  this 
exercise,  delete  the  File  and  CREATE  Primitives  from  EXAMPLE.  To 
change  EXAMPLE  from  a  Standard  Process,  as  it  now  is,  to  an  Item 
Passing  Process,  type, 

C  1  (cr) 

The  screen  will  display  the  form  originally  filled  out  for  EXAM¬ 
PLE.  Type  "ITEM"  over  the  existing  "STD"  in  START  field  TYPE. 
Entering  this,  the  screen  will  now  show  this  secondary  form  on 
which  Items  needed  by  this  Process  are  to  be  written,  as  shown  in 
Figure  43. 
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ITEM  PASSING  START 


ITEMS  RECEIVED: 


MUST  AU  THE  ITEM  SERIAL  NUMBERS  MATCH  (V/H) 


Figure  43.  Secondary  form  for  Process 

Type  the  single  Item  name  "MSG"  in  the  upper  left  field.  Enter¬ 
ing  this  changes  the  Process  representation  so  that  it  appears  as 
in  Figure  44. 


Figure  44.  Item  Passing  Process 

The  figure  to  the  left  of  the  Start  figure  indicates  that  the 
Process  starts  when,  and  only  when,  the  Item  MSG  is  delivered  to 
it  from  some  other  Process. 

None  of  the  Primitives  in  the  categories  Item  Handling  and 
Queue  Manipulation  represent  the  delivery  of  Items  to  a  Process. 
This  delivery  function  is  accomplished  by  the  Send.  To  exemplify 
Send,  a  new  Process,  called  "EXAMP-2",  must  be  created.  EXAMP-2 
triggers  the  execution  of  EXAMPLE  by  delivering  Items  to  it.  For 
this  example  consider  a  Process  identical  except  in  name  to  the 
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original  EXAMPLE  with  the  single  ACTION  Delay  as  depicted  in  Fig¬ 
ure  45. 
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Figure  45.  Process  with  ACTION  Primitive 
Type  the  command, 

P  SEND (cr) 

The  screen  will  display  the  form  shown  in  Figure  46. 


PARAMETERS  FDR  SEND 
SEND  ITEMS  TO  gj| 
ITEMS  TO  BE  SENT  ARE: 


S 


COMMENT: 


Figure  46.  Form  for  SEND  Primitive 

Complete  the  SEND  ITEMS  TO  field  with  EXAMPLE.  In  the  first 
field  of  ITEMS  TO  BE  SENT  fields,  type  MSG.  Enter  the  comment 
"SENDING  MESSGE  ITEM".  Figure  47  shows  the  graphic  representa¬ 
tion  of  the  Process  that  will  appear  on  the  screen. 
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Figure  47.  Graphic  Representation  of  EXAMP-2 

EXAMP-2  now  triggers  EXAMPLE  by  delivering  to  it  Items  required 
for  its  execution.  The  Item  is  automatically  created  by  the  Send 
Primitive.  An  Item-passing  Process  may  only  be  initiated  through 
the  SEND  Primitive  in  some  other  Process,  although  the  Items 
needed  and  hence  the  Items  sent  may  be  distributed  among  several 
Processes  or  several  stages  of  a  single  Process. 


3.7  RESOURCE  ALLOCATION 


As  mentioned  earlier.  Processes  in  an  AISIM  model  frequently  make 
use  of  Resources.  A  Resource  has  a  finite  capacity  which  will 
limit  the  number  of  Processes  it  can  accommodate  at  the  same 
time.  The  five  Primitives  which  relate  to  the  allocation  of  such 
Resources  are  ALLOC,  DEALLOC,  RESET,  LOCK  and  UNLOCK. 

ALLOC  and  DEALLOC  signal  the  allocation  and  deallocation  of 
a  Resource  by  the  Process  in  which  they  appear.  To  place  the 
ALLOC  Primitive  above  the  ACTION  Primitive  in  EXAMPLE,  type, 

P  ALLOC, 2  (cr) 

To  place  a  DEALLOC  Primitive  just  above  the  END  symbol  in  EXAMP- 
2,  type, 

P  DEALLOC  (cr) 
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The  forms  for  these  two  primitives  are  shown  below  in  Figure  48. 


In  each 
deal loc 
appropr 
COMMENT 

Placing 
below)  , 
ure  49. 


PARAMETERS  FOR  ALLOCATE : 
ALLOCATE  RESOURCE  NAME: 
COMMENT: 


PARAMETERS  FOR  DEALLOCATE: 
DEALLOCATE  RESOURCE  NAME: 

COMMENT:  ■■■■■■ 

% 


igure  48.  Forms  for  Primitives  ALLOC  and  DEALLOC 

case,  enter  the  name  of  the  Resource  to  be  allocated  or 
ted,  such  as  "CPU",  in  the  field  provided.  Enter  the 
ate  comment,  "OBTAINING  CPU"  or  "RELEASING  CPU"  in  the 
field. 

these  primitives  in  EXAMP-2  (one  above  the  ACTION  and  one 
produces  a  graphic  representation  like  that  shown  in  Fig- 
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Figure  49.  Process  which  Allocates  and  Deallocates  a  Resource 

Allocating  a  Resource  does  not  normally  insure  the  uninterrupted 
availability  of  that  Resource  to  a  Process.  Any  Resources  may  be 
usurped  by  a  Process  with  a  higher  priority.  If  the  Process 
being  modeled  is  one  which,  once  begun,  cannot  be  interrupted, 
the  Primitives  LOCK  and  UNLOCK  must  be  used. 

To  obtain  the  forms  for  these  Primitives  one  types, 

P  LOCK,n  (cr) 


or 


P  UNLOCK, n  (cr) 

where  n  is  the  position  in  the  Process  where  the  Primitive  is  to 
be  placed.  The  forms  for  these  Primitives  are  shown  in  Figure 
50. 
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PARAMETERS  FOR  LOCK: 


COMMENT : 

% 


PARAMETERS  FOR  UNLOCK: 

COMMENT:  ■■■ 
S 


Figure  50.  Forms  for  Primitives  LOCK  and  UNLOCK 

These  Primitives,  if  placed  below  the  ALLOC  Primitive  and  above 
the  DEALLOC  Primitive  in  EXAMP-2  would  give  a  graphic  representa¬ 
tion  like  that  shown  in  Figure  51. 


Figure  51.  Process  with  Protected  Resources 
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One  final  way  to  affect  a  Resource  is  through  the  RESET  Primi¬ 
tive.  It  is  used  to  reset  the  capacity  of  a  Resource,  where 
"capacity"  is  a  measure  of  the  number  of  Processes  it  will  accom¬ 
modate  (support)  at  one  time.  For  details  on  its  use,  see  the 
AISIM  User's  Manual ,  Section  3.9.18. 


3.8  CALL 

The  function  of  the  CALL  Primitive  is  similar  to  that  of  the  SEND 
Primitive,  but  whereas  the  SEND  Primitive  triggers  Item-passing 
Processes,  the  CALL  Primitive  triggers  both  Standard  Processes 
and  parameter-passing  Processes.  Thus,  to  understand  how  CALL 
works  requires  a  brief  discussion  of  parameter-passing  Processes. 

A  parameter-passing  Process  is  one  that  is  "given"  values  for 
input  variables  and  "returns"  values  for  output  variables.  To 
create  a  oaramater-passing  Process,  one  would  type  "PARM"  in  the 
field  STAP.T  TYPE  in  the  original  form  for  Process.  Entering  this 
information  on  the  Process  form  yields  the  secondary  form  shown 
in  Figure  52. 


PARAMETER  PASSING  START 
GIVEN: 


4 


Figure  52.  Secondary  Form  for  Parameter-passing  Process 

On  the  form  in  Figure  52,  one  types  the  variables  whose  values 
are  passed  to  the  Process  and  the  variables  whose  values  are 
passed  back. 

The  CALL  Primitive  values,  i.e.,  parameters,  are  passed 
(GIVEN)  to  a  called  Process  and  RETURNed  to  the  calling  Process. 
Parameter  passing  can  occur  only  through  the  use  of  a  CALL  Primi¬ 
tive.  A  CALL  Primitive  is  placed  in  a  Process  by  typing, 

P  CALL  (cr) 

The  form  for  CALL  is  shown  in  Figure  53. 
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PARAMETERS  FOR  CALL 


4 


CALLED- PROCESS  NAME: 

WAIT/ MOWA [ T /BLOCK :  m  PRIORITY: 

GIVEN: 


RETURNS: 


Figure  53.  Form  for  CALL  Primitive 

The  field  CALLED-PROCESS  NAME  asks  for  the  name  of  the  Pro¬ 
cess  to  be  triggered.  The  field  PRIORITY  determines  the  priority 
associated  with  the  called  Process  which  will  be  used  in  cases  of 
Resource  contention.  The  GIVEN  and  RETURNS  fields  hold  the  local 
variables  whose  values  are  passed  to  and  from  the  called  Process. 
A  CALL  Primitive  may  trigger  a  Standard  Process  and  hence  these 
fields  may  be  empty.  The  COMMENT  field  is  self-explanatory.  The 
field  labled  WAIT/NOWAIT/BLOCK  determines  whether  the  calling 
Process  will  wait  for  the  called  Process  before  continuing  execu¬ 
tion  or  will  continue  to  execute  independently  of  it.  The  reader 
is  referred  to  the  AISIM  User's  Manual  for  details  on  their  use. 


i 
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4.  REMAINING  MODEL  ELEMENTS 


Although  the  Processes  and  the  Architecture  are  core  model¬ 
ing  elements,  their  specification  does  not  complete  the  task  of 
model  construction.  They  must  be  supplemented  by  definitions  of 
other  elements.  These  elements  are  grouped  into  two  categories. 
The  first  category  consists  of  those  entities  explicitly  referred 
to  in  Processes,  namely,  Actions,  Constants,  (global)  Variables, 
Tables,  Queues  and  Resources.  The  second  category  consists  of 
the  two  entities  that  are  used  to  represent  the  impact  of  the 
environment  on  the  modeled  system.  All  these  remaining  entities 
are  defined  at  the  DUI  level  of  AISIM  operation. 

The  following  two  sections  briefly  describe  the  parameters, 
significance  and  principle  commands  associated  with  these  remain¬ 
ing  entities. 


4.1  ACTIONS 

Any  ACTION  Primitive  placed  in  a  Process  must  have  a  correspond¬ 
ing  Action  entity  defined  outside  the  Process.  Such  a  definition 
is  created  by  typing, 

E  ACTION, ACTION  NAME, NEW  (cr) 

The  form  for  the  Action  entity  is  shown  in  Figure  54. 


ACTION: 


CLASS: 

DESCRIPTION: 


Figure  54.  Form  For  Action  Entity 

The  ACTION  field  should  hold  the  name  of  an  Action  referenced  in 
some  ACTION  Primitive.  The  CLASS  is  an  optional  parameter  for 
the  user  to  provide  a  categor ization--man,  machine,  etc. —  of  the 
sort  of  activity  the  Action  represents.  It  functions  as  a  second 
comment  field.  This  field  does  not  affect  AISIM's  operation  and 
may  be  left  blank.  The  field  DESCRIPTION  is  for  any  convenient 
reminder  of  what  the  Action  represents.  It  can  be  the  same  as 
the  description  of  the  corresponding  Process  Primitive. 


4.2  RESOURCES 


As  mentioned  earlier,  any  Resource  mentioned  in  a  Process-- 
through  the  ALLOC,  DEALLOC,  FILE,  FIND  or  REMOVE  Pr imi t ives--must 
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be  defined  separately  in  the  PEI.  To  create  a  new  Resource, 
type, 

E  RESOURCE, NAME, NEW  (cr) 

The  screen  will  display  the  form  shown  in  Figure  55. 


RESOURCE  NAME : 

TOTAL  NUMBER  OF  UNITS'.  H 
INITIAL  NUMBER  OF  UNITS:  m 
ATTRIBUTES  PRESENT  <VES  OR  NO) 


COST:  m 
DESCRIPTION: 


Figure  55.  Form  For  Resource  Entity 

Complete  the  first  field,  RESOURCE  NAME,  with  the  name  by  which 
it  is  referred  in  any  Process.  The  fields  TOTAL  NUMBER  OF  UNITS 
and  INITIAL  NUMBER  OF  UNITS  indicate,  respectively,  the  maximum 
number  of  Processes  the  Resource  can  accommodate  at  any  one  time 
and  the  number  of  Processes  it  can  accommodate  at  the  beginning 
of  a  simulation  run  (i.e.,  before  being  increased  or  decreased  by 
the  RESET  Primitive).  Enter  the  appropriate  numbers.  The  field 
COST  functions  as  any  other  Resource  attribute.  DESCRIPTION  has 
its  usual  function.  Type  an  appropriate  description  in  the  field 
provided „ 

The  field  ATTRIBUTES  PRESENT  indicates  whether  the  Resource  has 
associated  with  it  attributes  other  than  "COST"  which  can  be 
referred  to  and  manipulated  by  the  Primitives  ASSIGN  and  EVAL. 

If  the  user  enters  "YES"  in  this  field,  he  will  be  offered  the 
following  secondary  form  shown  in  Figure  56. 
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ATTPi BuTES 


WAlu£ 


Figure  56.  Form  For  Attributes  of  an  Entity 

Up  to  fifteen  attribute  names  may  be  entered  with  their  initial 
values. 

Though  all  Resources  referred  to  require  separate  definitions, 
some  Resources  are  defined  automatically.  For  each  node  or  link 
created  in  a  model's  network  architecture,  a  Resource  definition 
of  the  same  name  with  default  parameters  is  automatically  written 
into  the  database.  In  other  words,  all  nodes  and  links  are  iden¬ 
tified  with  Resources.  Thus,  after  an  architecture  has  been 
created  the  command. 


E  RESOURCE, 


nodename 
1 inkname 


can  be  issued  without  having  to  indicate  that  the  Resource  entity 
is  new  (with  "NEW").  Typically,  however,  not  all  of  a  system's 
Resources  will  be  represented  in  the  architecture  and  not  all  of 
the  Resources  automatically  created  in  ADE  will  have  any  positive 
role  in  the  operation  of  the  model.  That  is,  such  automatically 
defined  Resources  need  not  be  invoked  in  the  Process  primitives. 
Importantly,  if  an  operative  Resource  is  to  be  identified  with  an 
architectural  element,  it  should  be  defined  first  in  ADE  and 
thereafter  edited  to  provide  it  with  suitable  parameters  (on  the 
assumption  that  the  default  parameters  are  incorrect).  ADE  will 
not  allow  the  definition  of  a  node  or  link  whose  name  is  identi¬ 
cal  with  that  of  a  Resource  already  in  existence. 
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4  .  3  QUEUES 


Not  all  the  Queues  functioning  in  a  system  model  need  be  defined 
by  the  user,  since  many  are  implicit  in  the  operation  of  the  sys¬ 
tem.  The  general  rule  is  that  any  Queue  manipulated  by  the  FILE, 
FIND  or  REMOVE  Primitives  must  be  given  a  separate  definition  in 
the  DU I ,  with  the  exception  of  these  two: 

--any  Resource  idle  queue 

--any  cross-reference  set 

These  are  explained  in  the  AISIM  User's  Manual ,  Appendix  D. 

To  define  a  new  Queue,  type, 

E  QUEUE, NAME, NEW  (cr) 

The  form  for  this  entity  is  shown  in  Figure  57. 


QUEUE: 


SIZE: 


DESCR: 

<• 


Figure  57.  Form  for  Queue  Entity 

The  three  fields  should  be  filled  in  with,  respectively,  (a)  the 
name  of  the  Queue  as  found  in  the  FILE,  FIND, or  REMOVE  Primitive 
which  invokes  the  Queue,  (b)  the  maximum  number  of  Items  or 
Resources  that  can  be  placed  in  it  {the  default  value  for  which 
is  "infinite")  and  (c)  any  useful  reminder  of  the  Queue's  role  in 
the  modeled  system. 


4.4  CONSTANTS  AND  VARIABLES 


Constants  differ  from  global  Variables  only  in  that  they  do 
not  change  their  values  during  the  simulation  exercise  of  a 
model.  This  can  be  puzzling  at  first  since  Constants,  like  Vari¬ 
ables,  are  represented  by  non-numeric  symbols.  Also  from  the 
user's  point  of  view,  however,  they  behave  quite  similarly  since 
they  can  both  be  altered  immediately  before  the  simulation  exer¬ 
cise  of  a  model.  However,  once  a  value  has  been  assigned  to  a 
Constant  and  a  simulation  is  begun,  its  value  is  unchanging. 
Accidental  attempts  to  alter  the  value  of  a  Constant  through  the 
EVAL  or  ASSIGN  primitives  will  yield  an  execution  error  message. 
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The  forms  for  Constants  and  Variables  are  quite  similar  and  are 
called  up  by  issuing  the  command  ”E"  or  “EDIT"  followed  by  a 
space  and  "CONSTANT"  or  "VARIABLE",  then  a  comma  and  the 
Constant's  or  Variable's  name. 

The  forms  for  Constant  and  Variable  are  shown  in  Figure  58. 


CONSTANT; 

VALUE;  m 
DESCRIPTION: 


VARIABLE:  H| 
VALUE: 

DESCRIPTION: 


Figure  58.  Forms  for  Constant  And  Variable 

The  fields  CONSTANT  and  VARIABLE  call  for  the  entities'  names. 
The  VALUE  fields  call  for  numerical  values  (initial  for  Vari¬ 
ables,  permanent  for  Constants)  and  the  DESCRIPTION  fields  call 
for  any  description. 


4.5  LOADS  AND  SCENARIOS 


The  effect  of  the  environment  on  a  model  is  represented  collec¬ 
tively  by  Loads  and  Scenarios.  The  relationship  between  Loads 
and  Scenarios  is  this:  Loads  specify  a  number  of  Process  trigger 
ings  to  take  place  sometime  during  the  simulation  exercise  of  a 
model.  Loads  do  not  specify  when  the  Process  triggerings  are  to 
take  place.  Scenarios  specify  a  collection  of  Loads  and/or  indi 
vidual  Processes  together  with  a  schedule  indicating  when  the 
specified  Loads  or  Processes  are  to  be  initiated. 

To  define  a  Load,  type 

E  LOAD, NAME, NEW  (cr) 

Tha  form  for  the  Load  Entity  is  shown  in  Figure  59. 


.3A0: 
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The  LOAD  field  holds  the  name  of  the  Load.  The  fields  labeled 
NODE  1  through  NODE8  indicate  the  architectural  nodes  in  which  the 
Processes  named  in  the  Load  take  place.  The  field  DESCR  is  for 
any  helpful  description. 

The  field  labeled  PROCESS  holds  up  to  five  names  of  Processes. 

The  fields  SOHMDT,  MEAN  and  DELTA  together  define  the  statistical 
method  of  distribution  to  be  used  in  scheduling  the  Process 
triggerings.  SCHMDT  holds  the  name  of  the  distribution  method; 
MEAN  holds  the  average  time  between  Process  initiations  (in  terms 
of  the  simulation  clock)  and  DELTA  is  a  second  numerical 
parameter  used  only  for  certain  methods.  The  field  MAX  #  indi¬ 
cates  the  maximum  number  of  Process  instances  to  be  initiated  by 
this  Load. 

The  Scenario  entity  defines  the  impact  of  the  environment  on  the 
system  for  the  entire  simulation  exercise  of  a  model.  In  it  one 
specifies  a  number  of  "periods"  into  which  a  simulation  exercise 
is  to  be  divided,  together  with  a  uniform  length  each  period  is 
to  have.  One  then  specifies  a  collection  of  Loads  or  Process  to 
be  initiated  at  a  specified  time  during  the  simulation.  A  prior¬ 
ity  is  also  given  to  resolve  conflicts  in  the  requests  for 
Resources. 

To  define  a  Scenario,  type, 

E  SCENARIO, NAME, NEW  (cr) 

The  form  for  the  Scenario  entity  is  shown  in  Figure  60. 
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SCENARIO: 


PERIOD  LENGTH: 


DESCRIPTION: 


•3> 


Figure  60.  Form  for  Scenario  Entity 

The  field  SCENARIO  holds  the  name  of  the  entity.  PERIOD  LENGTH 
is  the  length  of  each  period.  The  14  fields  labeled  PERIODS  are 
used  to  indicate  the  number  of  periods  the  Scenario  is  to  have. 
The  number  of  periods  in  the  Scenario  is  determined  by  the  number 
of  these  fields  in  which  an  entry  is  made.  Any  user-defined 
names  (i.e.,  any  characters)  may  be  typed  in  these  fields. 

The  fields  labeled  TRIGGER  take  the  name  of  the  Load  or  Process 
to  be  initiated.  The  fields  SCH  TIME  indicate  the  time  at  which 
the  Load  or  Process  named  immediately  to  the  left  is  to  be  ini¬ 
tiated.  The  field  PRIORITY  is  used  to  assign  a  priority  to  the 
named  Load  or  Process. 
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5.  A  WORKING  EXAMPLE 


This  section  documents  the  construction  of  an  AISIM  model 
that  can  be  run  through  simulation  tests  and  analyzed  in  the  sub¬ 
sequent  chapter.  The  model  will  be  a  representation  of  the 
transmitter/receiver  relationship,  an  element  of  any  communica¬ 
tion  system. 

The  transmitter/receiver  relation  modeled  here  is  of  the  "pol¬ 
ling"  or  "mailbox"  type,  as  opposed  to  the  "interrupt"  type.  In 
it,  one  transmitting  Process  generates  messages  and  delivers  them 
to  a  buffer.  There  the  messages  await  treatment  from  a  receiving 
Process.  The  transmitting  and  receiving  Processes  are  not  in 
direct  communication  with  one  another.  Rather,  the  transmitter 
broadcasts  messages  according  to  need,  and  the  receiving  Process 
reads  them  from  the  buffer  at  intervals  in  accordance  with 
expected  need.  In  the  system  envisioned,  transmission  is  random¬ 
ized  in  two  respects,  (1)  in  the  lengths  of  transmitted  messages 
and  (2)  in  the  intervals  between  transmission.  Reception  is 
undertaken  at  regular  intervals  and  the  time  consumed  in  process¬ 
ing  a  message  is  a  linear  function  of  its  length. 

The  origination  of  a  message  in  the  transmitting  Process  will  be 
represented  by  the  creation  of  an  Item  (through  the  CREATE  Primi¬ 
tive).  The  Item  will  have  a  variable  attribute  which  will 
represent  its  length.  Since  the  length  will  be  randomized  over  a 
range  of  approximately  700  bytes,  some  mechanism  must  be  incor¬ 
porated  for  altering  the  variable  attribute  of  each  data  Item 
(i.e.,  message).  This  is  accomplished  by  (1)  generating  a  random 
number  in  the  range  [0,1]  subsequent  to  the  creation  of  each 
Item,  (2)  multiplying  the  random  number  by  twice  the  average  mes¬ 
sage  length  and  (3)  assigning  the  number  so  obtained  to  the  mes¬ 
sage  length.  This  figure  will  then  be  used  to  calculate  the  time 
taken  to  send  the  message  to  the  buffer  (where  it  will  be  avail¬ 
able  to  the  receiving  Process) .  Through  an  ACTION  Primitive,  the 
clock  is  then  updated  in  the  amount  calculated. 

In  this  system  the  buffer  will  not  be  manipulated  by  both 
the  receiving  and  the  transmitting  Processes  at  the  same  time,  so 
the  buffer  is  considered  a  Resource  and  its  allocation  and  deal¬ 
location  by  the  ALLOC  and  DEALLOC  Primitives  will  prevent  it  from 
being  accessed  simultaneously  by  both  Processes. 

5.1  DEFINING  PROCESSES 

This  description  of  the  transmitting  Process  gives  the  steps 
of  its  execution.  The  transmitting  Process: 

(1)  Starts 

(2)  Allocates  a  Resource  BUF1  representing  the  buffer 
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(3)  Creates  a  message,  represented  as  an  Item  called  "msg 

(4)  Generates  a  random  number  between  0  and  1 


{  (5)  Multiplies  the  random  number  generated  by  twice  the 

j  average  message  length 

i  (6)  Assigns  the  number  obtained  in  the  previous  step  to 

the  Item  attribute  representing  the  message  length 

(6)  Updates  the  clock  by  an  amount  proportional  to  the 
message  length  (i.e.,  in  an  amount  equal  to  the  message 
length  times  the  transmission  rate  in  seconds  per  byte) 

(7)  Delivers  the  message  Item  to  the  Queue  called  Buffer 
through  the  FILE  Primitive. 

(8)  Releases  the  Resource  BUF1  representing  the  buffer 
Figure  61  shows  Process  flow-chart  derived  from  this  description. 
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The  receiving  Process  will  first  determine  whether  or  not 
the  buffer  is  being  manipulated  by  the  other  Process  by  testing 
for  utilization  of  the  Resource  call  BUF1.  If  the  Resource  is  in 
use,  the  Process  will  abort  by  branching  to  the  END  symbol.  If 
BUF1  is  free,  the  Process  will  read  the  next  message  from  the 
buffer,  and  calculate  a  receiving  time  in  roughly  the  same  way 
that  the  transmitting  time  for  that  same  Item  was  determined  in 
the  transmitting  Process.  The  clock  is  then  updated  by  the 
amount  of  time  calculated. 

This  description  can  be  expanded  into  more  specific  design 
requirements.  The  receiving  Process  will: 

(1)  Start. 

(2)  Test  for  the  availability  of  the  buffer  by  determining 
whether  or  not  the  Resource  is  in  use  through  the  TEST 
Primitive.  If  so,  the  Processes  execution  will  branch  to 
the  END  symbol. 

(3)  The  next  message  Item  on  the  Queue  called  buffer  will 
be  read  off  through  the  REMOVE  Primitive. 

(4)  If  there  is  nothing  on  the  buffer.  Process  execution, 
as  in  step  (2),  will  branch  to  the  End.  This  step  will  be 
represented  by  a  COMPARE  Primitive. 

(5)  The  message  length  will  be  assigned  to  a  local  vari¬ 
able  through  the  ASSIGN  Primitive. 

(6)  A  receiving  time  will  be  calculated  to  be  proportional 
to  the  message  length  (i.e.,  equal  to  the  message  length 
times  some  reception  speed  in  seconds  per  byte)  . 

(7)  The  clock  will  be  updated  through  the  ACTION  Primitive 
in  the  amount  required  to  receive  the  message. 

(8)  The  message  Item,  having  been  read,  will  be  eliminated 
from  the  system  through  the  DESTROY  Primitive. 

(9)  An  ENTRY  Primitive  will  be  inserted  just  before  the 
END  symbol  of  the  Process  to  indicate  where  execution  is 
to  resume  from  the  branchings  in  steps  (2)  and  (4). 

Figure  62  shows  the  flow-chart  representation  of  the  Process 
derived  from  these  requirements. 
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5.2  REMAINING  MODEL  ELEMENTS 


The  remaining  model  entities  must  now  be  defined.  These  include 
all  the  entities  mentioned  in  any  Process  Primitive.  These  are 
the  following: 

1)  The  Queue  named  "BUFFER"  onto  which  messages  are  filed; 

2)  The  Resource  BUF1  which  represents  a  device  to  protect  the 
buffer  against  manipulation  by  two  Processes  at  once; 

3)  The  Item  MSG,  each  instance  of  which  is  to  represent  a  mes¬ 
sage  transmitted  onto  the  Queue; 

4)  The  global  Variables. 

5)  The  Action  entities. 

5.2.1  RESOURCE  DEFINITIONS 

The  Resource  BUF1  is  given  proper  parameters.  It  will  have 
only  one  initial  unit  and  will  have  a  maximum  of  one.  It  will 
retain  the  default  of  no  attributes  and  a  cost  of  zero.  An 
appropriate  description  is:  "RESOURCE  ASSOCIATED  WITH  BUFFER". 


5.2.2  QUEUE  DEFINITIONS 

The  Queue  called  "BUFFER",  which  is  accessed  by  the  FILE  and 
REMOVE  Primitives,  will  retain  its  default  value  of  "INFINITE" 
holding  capacity.  A  helpful  description  is:  "BUFFER  ON  WHICH 
MESSAGES  ARE  STORED". 


5.2.3  ITEM  DEFINITION 

The  Item  MSG  which  represents  messages  transmitted  and  received 
will  have  one  attribute  called  "LENGTH".  Its  initial  value  will 
be  the  Literal  "SLENGTH" ,  since  the  value  of  this  attribute  will 
always  be  assigned  within  the  Process  that  transmits  it  to  the 
buffer . 

5.2.4  VARIABLE  DEFINITION 

The  Variables  "GAMMA1"  and  "GAMMA2"  are  defined  with  initial 
values  of  .700  and  .002  respectively.  These  values  are  used  in 
calculating  the  transmition  and  reception  time.  GAMMA1  is  the 
average  message  length,  and  GAMMA2  is  the  transmition  rate. 

5.2.5  ACTION  DEFINITION 

Action  entities  "SENDING"  and  "READ-MSG"  must  be  defined  in  order 
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to  satisfy  the  references  in  the  action  Primitives  in  the 
Processes  TRANSMIT  and  RECEIVE.  The  class  and  description  fields 
can  be  filled  in  as  desired  by  the  user.  These  fields  have  no 
effect  on  the  simulation. 

5.3  LOADS  AND  SCENARIOS 


Finally,  we  must  define  the  hypothetical  conditions  to 
which  the  modeled  system  will  be  exposed.  Six  Loads  are  defined 
for  this  model.  LI,  L2  and  L3  each  trigger  the  transmitting  Pro¬ 
cess.  LI 1 ,  L22  and  L33  each  trigger  the  receiving  Process  in  a 
schedule  of  expected  need  associated  with  LI,  L2  and  L3.  The 
triggerings  of  the  transmitting  Process  are  randomized,  whereas 
the  triggerings  of  the  receiving  Process  are  scheduled  at  regular 
intervals.  The  complete  Load  definitions  are  found  on  pages  3 
through  5  of  the  Model  Verification  Report  which  appears  in 
Appendix  A. 

The  Scenario  for  this  model  consists  of  six  periods.  The 
Loads  are  distributed  throughout  the  simulation  period  as  fol¬ 
lows:  each  pair  of  Loads  is  triggered  at  intervals  of  200  units 
on  the  simulation  clock.  The  complete  definition  is  found  on 
page  5  of  the  Model  Verification  Report  in  Appendix  A. 
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SIMULATION  EXERCISES  OF  AISIM  MODELS 


The  model  is  now  ready  to  be  run  through  a  simulation  exercise  to 
determine  its  behavior  under  the  defined  environmental  condi¬ 
tions.  To  begin  this  exercise,  enter  the  Analysis  User  Interface 
(AUI)  from  the  AISIM  READY  level  by  typing, 

A  P (pro jectname) 

Pro jectname  is  the  name  of  the  model  we  wish  to  expose  to  a  simu¬ 
lation  exercise.  The  user  will  be  prompted  with  information  that 
will  look  something  like  that  shown  in  Figure  63. 


CURRENT  PARAMETERS  IN  EFFECT: 

VERSION:  PRODUCTION 

PROJECT:  TESTDBC 

USER:  TF01S08 

ILATE/NOIIATE:  KATE 

'ENTER  f£S  TO  PROCEED,  NO  TO  ABORT...' 


Figure  63.  Information  Displayed  on  Entering  The  AUI 
After  declining  the  abort  prompt  by  typing 
YES  (cr) 

and  following  the  translation  of  the  model,  the  user  is  in  a 
position  to  issue  commands  before  the  execution  of  the  simula¬ 
tion. 

6.1  INITIALIZING  A  MODEL 

If  more  than  one  Scenario  has  been  defined,  the  system  will 

ask , 

WHICH  SCENARIO  DO  YOU  WISH  TO  TRANSLATE? 

Type  the  name  of  the  Scenario  that  defines  the  environmental  con¬ 
ditions  to  which  the  model  is  to  be  subjected.  For  this  model, 
we  have  defined  only  one  Scenario  so  the  program  will  perform 
model  initialization.  If  no  errors  are  detected  at  this  stage 
the  computer  will  prompt  with, 

NO  ERRORS  DETECTED  DURING  MODEL  INITIALIZATION 
YOU  MAY  NOW  ENTER  COMMANDS 

If  an  error  had  been  made  the  computer  would  have  prompted  with. 
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ERRORS  DETECTED  IN  MODEL  INITIALIZATION 

This  prompt  indicates  that  some  aspect  of  the  model  definition  is 
in  error.  If  such  is  the  case,  determine  what  the  errors  are, 
see  Appendix  B  of  the  AISIM  User's  Manual ,  and  return  to  the  DUI 
to  correct  them.  The  matter  of  getting  to  the  DUI  has  already 
been  covered  in  previous  chapters.  For  this  example,  assume  that 
the  AISIM  model  is  properly  defined. 

6.2  DEFINING  PLOTS 

Two  choices  are  available  at  this  point:  Proceed  to  the  simula¬ 
tion  exercise  of  the  model  o_r  request  that  graphs  of  some  of  the 
activities  monitored  during  the  simulation  be  defined  so  that 
they  can  later  be  inspected  at  the  terminal. 

For  example,  in  the  model  under  consideration,  one  of  our 
main  concerns  is  to  determine  whether  the  buffer  onto  which  the 
transmitting  Process  places  messages  (and  from  which  the  receiv¬ 
ing  Process  retrieves  the  messages)  reaches  some  maximum  burden 
or  whether  it  shows  a  tendency  to  infinite  queueing.  To  produce  a 
graph  of  the  behavior  of  the  buffer  we  type, 

DEFPLOT  QUEUE, BUFFER 

The  screen  will  display  selection  of  aspects  of  the  behavior  of  a 
Queue  of  which  a  graph  can  be  defined.  These  are  shown  in  Figure 
64. 

ATTRIBUTES  (PLACE  AN  I  NEIT  TO  QNLT  ONE) 

INUM8ER  IN  QUEUE 
NUMBER  BLOCKED 
TINE  IN  QUEUE 
TINE  BLOCKED 

s 


Figure  64.  Aspects  of  Queue  Behavior 

To  define  a  graph  showing  the  number  of  Items  in  the  Buffer  we 
would  enter  an  "x"  for  "NUMBER  IN  QUEUE".  The  screen  would  then 
display  the  options  for  defining  the  type  statistic  on  the  number 
of  Items  in  the  Queue.  These  options  are  shown  in  Figure  65. 
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STATISTICS  (PLACE  AH  I  NEXT  TO  ONir  ONE) 


CURRENT 

CUMULATIVE  MEAN 
CUM  STANDARD  DEV 
CUMULATIVE  HIM 
CUMULATIVE  MAX 
PERIOD  MEAN 
PER  STANDARD  DEV 
PERIOD  MIN 
PERIOD  MAI 
V 


Figure  65.  Options  for  Statistics 

To  calculate  the  current  number  of  message  Items  in  the 
Queue  called  "BUFFER"  at  any  given  time,  enter  an  "x"  next  to 
"CURRENT”.  The  entities  with  respect  to  which  graphs  can  be 
defined  are  Resources,  Queues,  Processes,  Items  and  Variables. 
Up  to  ten  such  graphs  may  be  defined  per  analyze  session. 

6.3  STARTING  THE  SIMULATION 


Once  the  model  is  initialized  and  graphs  are  defined  the 
model  may  be  executed  through  a  simulation  run.  The  execution  of 
the  model  may  be  triggered  either  for  the  entire  Scenario  or  for 
a  specified  number  of  periods,  so  that  global  Variables  can  be 
given  initial  values  different  from  those  previously  defined  in 
the  DUI . 

The  values  of  Constants  and  the  initial  values  of  global  Vari¬ 
ables  may  also  be  changed  before  a  simulation  exercise  begins. 

The  latter  option  will  be  chosen  in  this  example  to  investigate 
the  effect  of  altering  the  time  required  to  transmit  or  to  pro¬ 
cess  message  Items.  To  begin  the  simulation,  type, 

GO  1 

This  command  indicates  that  the  simulation  is  to  be  run  for  1  of 
the  10  simulation  periods  defined  when  the  model  was  created  in 
the  DUI.  When  this  first  stage  of  the  simulation  is  completed 
the  screen  will  offer  the  following  message: 

END  OF  PERIOD 

YOU  MAY  NOW  ENTER  COMMANDS 


6.4  EDITING  VARIA iLES  BETWEEN  SIMULATION  STAGES 


To  change  the  value  of  a  variable,  issue  the  appropriate  command 
with  information  as  to  (a)  the  type  of  entity  to  be  edited,  (b) 
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the  name  of  the  entity  whose  value  is  to  be  changed  and  (c)  the 
new  numerical  value  of  the  entity.  The  Variable  gamma2  formerly 
had  the  value  of  .002.  To  change  it  to  .001,  type. 


E  V,gamma2, . 001 

The  simulation  may  be  continued  for  two  more  periods  by  typing, 

GO  2 

When  this  stage  of  the  simulation  is  completed  the  value  of  Vari¬ 
ables  may  be  changed  back  to  .002  by  typing, 

E  V,gamma2, .002 

To  command  that  the  the  remainder  of  the  Scenario  be  run  through 
without  further  interruption,  type  the  GO  command  without  a 
numeric  parameter,  thus: 

GO 

If  no  mistakes  were  made  in  constructing  the  model  that 
cause  the  simulation  to  abort,  the  computer  will  prompt,  after 
some  time,  that  the  simulation  is  completed. 

The  output  report  for  this  simulation  run  appears  in  Appen¬ 
dix  A. 
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7.  A  MORE  ELABORATE  EXAMPLE 


In  this  chapter  a  communication  system  slightly  more  compli¬ 
cated  than  that  designed  in  Chapter  5  and  analyzed  in  Chapter  6 
is  constructed.  To  do  this,  however,  requires  that  we  introduce 
one  further  AISIM  feature. 


7.1  MESSAGE  ROUTING  SUBMODEL 


When  one  Process  is  triggered  by  another  through  a  Call 
primitive,  the  called  Process  will  execute  in  the  same  architec¬ 
tural  node  as  the  one  that  triggered  it,  i.e.  utilize  the  same 
Resource,  even  if  the  two  Processes  are  normally  associated  with 
different  nodes.  This  is  inconvenient  in  the  representation  of 
communication  systems  in  which  an  activity  in  one  hardware  ele¬ 
ment  causes  activity  in  another  one.  AISIM  therefore  embodies  a 
submodel  to  represent  the  situation  in  which  a  Process  in  one 
node  triggers  a  Process  in  another  node  by  communicating  through 
the  network  architecture.  This  submodel  consists  of  a  collection 
of  Processes  and  one  Item. 

The  Processes  that  accomplish  this  must  be  placed  in  a  project 
database  with  the  commands  available  in  the  Library  User  Inter¬ 
face.  The  entities  of  this  submodel  need  not  be  defined  anew. 

For  information  on  the  use  of  this  facility,  see  the  AISIM  User 1 s 
Manual ,  Section  10. 

7.2  DEFINING  ARCHITECTURAL  ELEMENTS 


Consider  modeling  a  communication  system  between  two  air¬ 
bases,  a  headquarters  and  a  command  headquarters  that  communi¬ 
cates  directly  with  a  computer  disk.  Between  these  end-points 
are  switches  that  govern  the  routing  of  messages  through  the  sys¬ 
tem.  The  physical  layout  of  this  system  is  shown  in  Figure  66. 
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1.  V* 


Figure  66.  System  Architecture 

For  this  example,  the  shortest  paths  between  the  nodes  will  be 
used.  Therefore,  subsequent  to  defining  the  architecture,  method 
B  is  used  to  create  the  Legal  Path  Table.  The  resulting  table  is 
depicted  in  the  analysis  report  given  in  Appendix  B. 

The  operations  associated  with  this  architecture  are  as  fol¬ 
lows.  Both  airbases  periodically  broadcast  messages  to  the 
other  nodes  in  the  system  and  request  plans  from  the  command 
headquarters . 

The  effect  of  each  broadcast  is  to  (1)  stimulate  processing  in 
the  HQ  and  CHQ  and  to  cause  the  updating  of  information  in  all 
other  nodes.  Periodically  also  an  applications  program  in  L3 
requests  plans  from  the  CHQ,  as  do  also  AB1  and  AB2.  The  effect 
of  any  such  request  is  to  engage  the  operation  of  the  disk  that 
communicates  directly  (and  only)  with  the  CHQ. 

This  description  of  the  main  operations  of  the  system 
implies  the  following  more  rigorous  listing  of  the  Processes  that 
need  to  be  defined  to  represent  such  a  system.  The  Processes 
requi red  will  be : 

--A  Process  to  represent  the  request  from  the  HQ  to  the 
CHQ  for  plans.  It  will  execute  in  the  HQ  node  and  will 
trigger  a  Process  in  the  CHQ  node. 

--A  Process  to  represent  the  broadcast  of  data  from  AB1 
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and  AB2  to  all  other  nodes.  This  Process  will  execute  in 
the  nodes  AB1  and  AB2  and  will  trigger  (a)  an  updating 
Processes  in  (a)  the  HQ  node,  (b)  the  CHQ  node  and  (c) 
each  other,  i.e.,  a  broadcast  in  one  airbase  will  update 
information  in  the  other. 

— A  Process  to  represent  the  updating  activity  that  occurs 
in  the  CHQ,  triggered  by  broadcasts  from  the  airbases. 

— A  Process  to  represent  the  updating  activity  that  occurs 
in  the  HQ  that  is  triggered  by  broadcasts  from  the  air¬ 
bases  . 

— A  Process  to  represent  the  updating  activity  in  the  air¬ 
bases  which  is  triggered  by  broadcasts  from  one  another. 

— A  Process  to  represent  the  formulation  of  plans  at  the 
CHQ,  which  is  triggered  by  requests  from  AB1 ,  AB 2  and  HQ. 
This  Process  executes  in  the  CHQ  node  and  triggers  another 
Process  representing  disk  operation  in  the  Disk  node. 

— A  Process  to  represent  the  operation  of  the  disk  that 
communicates  with  the  CHQ  node. 

These  descriptions  can  be  used  to  generate  the  AISIM  Pro¬ 
cess  definitions  found  on  the  following  pages.  The  Pro¬ 
cess  flow-charts  for  each  are  displayed,  together  with 
annotations  to  clarify  the  rationale  for  the  steps  that 
might  otherwise  be  obscure. 
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AIRBASE  REQUEST  FOR  PLANS  REPORT  FRC.1  CHQ 
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7.3  DEFINING  REMAINING  MODEL  ELEMENTS 


The  components  of  the  model.  These  must  include  (1)  all 
Resources  accessed  in  the  Processes  (2)  all  Actions  which  appear 
as  Primitives;  (3)  all  Constants  and  global  Variables  invoked  in 
the  Processes;  (4)  Loads;  and  (5)  Scenarios. 

7.3.1  RESOURCE  DEFINITIONS  All  the  Resources  necessary  to  this 
model  will  have  been  defined  automatically  with  default  values 
while  representing  the  physical  layout  represented  in  the  Archi¬ 
tecture  Design  Editor.  Thus,  if  the  nodes  and  links  have  the 
same  names  as  in  Figure  66  above,  the  following  list  of  Resources 
will  already  exist  in  the  model  database. 


*11  Resource  r o*  MM 

*K  Resource  TOR  MM 

CM  COVtMC  Klt-HimK 
cm.*  RCSOUtCe  rot  CNMHCl  CSMCCTM 

On. I  resource  rw  CMMtl  COMCCTM 

CM.*  RCSOUtCT  TBt  CMMtl.  CQMtCTDR 

CM.*  KSOURCC  m  CMMtl  COMtCTOR 

CM.*  «CMUK£  TOR  CMMtl  CSMttTDff  (MUMC  MW*  VHX) 

CM3. 1  RCSOURCC  rot  CMMtl  COMtCTM  tOOUSlt  MfMU  SKU» 

MM.*  RCSOURCC  rot  CMMtl  COMtCTM  (fioUMC  MffMl  SKO) 

CM. I  resource  TOR  CMMtl  COMtCTM  CDOU1U  MMMi  srersi 

CM.*  MSOUtCC  rw  CMMtl  COMtCTM  CMUHC  MtMt  SHUI) 

CM. I  MSOUtCC  rw  CMMtl  COMtCTM  I00M1C  MMMI  IRCD) 


vm.tr 

■SMti  rw  cmm«i  camtcTw 

CM  7 .1 

RCSOURCC  TW  CMMtl l  COHHtCIO* 

CM.* 

H samel  rw  cimmiCi  cohhccto* 

Ml 

K$0U*Ct  TM  CNMMCl  COIMt  CTO* 

CM.* 

CtSOUiCl  TM  CMMtl  COMtCTM 

CM.* 

Resource  rw  cmumci  comcctm 

*( 

•ISR  TM  CtRUUMP  RCM-MMRTltS 

M 

RUO-RUMTCtS 

U 

Resource  TM  MM 

Ml 

much  imen  *ic**sn  *m  dticr  tm  mucus  uiti 

MG 

MITCH  RmtC*  MITCH  1  t  1  *M  M 

MO 

MITCH  KTICCH  MITCH  UlMCM 

Figure  67.  Defined  Resource  Entities 

Since  these  Resources  are  created  with  default  values  (an  initial 
unit  of  1,  a  maximum  unit  of  1,  no  attributes  attached,  a  cost  of 
0,  and  no  description),  they  must  be  edited  to  provide  helpful 
descriptions  and  to  give  them  attributes  since  attributes  of 
these  Resources  are  accessed  in  several  places  in  the  Message 
Routing  Submodel.  Descriptions  and  attributes  can  be  edited 
before  generating  the  architecture  using  the  ADE’s  DEFINE  com¬ 
mand.  See  Section  2.1  of  this  manual. 


7.3.2  FILLING  IN  THE  ACTION  DEFINITIONS  The  Action  Primitives 
invoked  in  the  Processes  must  have  corresponding  Action  entity 
definitions  outside  the  Process.  The  ones  invoked  are  these: 


:  ■  ■  :  oh 

C  "*0  .  Cn 

cs .  ;.h 

-_-m»  ACT 
FC^aT 

hQ.CH 

latenct 
O'.  E°HE40 
CQ'jTE  .OH 

c  z  cy 

U"DAT£ 
■EES 
■  FE 9 .OH 


CHQ  c=CCESSING  OF  GRAPHICS  PEOUEST 
CWQ  PROCESSING  OF  HAPO  COPT  REQUEST 
PPCCESSING  TO  PERFORM  CONTEXT  SWITCHING 
ACTION  TO  ENABLE  crciic  PROGRAM  CfCLES 
TIKE  USEO  TO  FORMAT  PLANS  FROM  CHQ 
HQ  PROCESSING  OF  MESSAGE 
LATENCT  PAUSE  SUBSEQUENT  TO  SEEK 
TIME  FCR  GENERAL  USE 
PROCESSING  OELAT  TO  ROUTE  A  MESSAGE 
SEEPING  INFORMATION  CN  OISK 

UPDATING  INFO  SINCE  PREVIOUS  BROADCAST  TO  OTHER  NOEES 

TRANSFER  INFORMATION  SOUGHT  ON  DISK 

PROCESSING  OELAT  TO  ROUTE  A  MESSAGE  OVER  A  CHANNEL 


Figure  68.  Defined  Action  Entities 

7.3.3  CONSTANTS  AND  GLOBAL  VARIABLES  This  model  contains  five 
global  Variables  (ABDRATE,  ABRATE,  HQRATE ,  TIME1  and  VRATE)  and 
one  Constant  (V. TRACE) .  Their  defined  values  and  descriptions 
(which  explain  their  role  in  the  model)  are  as  follows: 


ABDRATE 

Interval 

between  signals. 

ABRRATE 

Interval 

between  signals. 

HQRATE 

Interval 

between  signals. 

TIME1 

Average 

seek  times  for  disk  in  milliseconds. 

VRATE 

Switch  to  other  node  channel  speed  in  ms/byte 

7.3.4  DEFINING  LOADS  AND  SCENARIOS  In  this  model  we  wish  to 
represent  the  several  Process  triggerings  that  are  due  to  causes 
outside  the  system.  First,  the  ABl  and  AB2  will  broadcast  com¬ 
munications  to  the  oth°r  nodes  (which  trigger  updating  Processes 
in  them)  every  minut'  by  an  interval  scheduling  method.  In 
addition,  ABl  and  AL  will  issue  requests  for  plans  from  the  CHQ 
sixty  times  in  one  hour  by  an  exponential  scheduling  method.  We 
define  a  second  Load  to  represent  requests  from  the  leaf-node, 

L3,  also  for  plans  from  the  CHQ.  This  Process  will  also  be 
undertaken  sixty  times  per  hour,  exponentially  distributed.  The 
Load  definitions  implied  by  these  requirements  are  printed  in 
Appendix  B. 

The  length  of  the  entire  Scenario  is  360,000  milliseconds 
(one  hour),  which  is  divided  into  ten  periods  of  six  minutes 
each.  To  simulate  the  operation  of  the  system  with  the  worst 
case,  we  stipulate  that  both  of  the  functional  Loads  are  trig¬ 
gered  simultaneously,  at  the  beginning  of  the  Scenario.  In  addi¬ 
tion,  as  a  monitoring  device,  we  initiate  the  Trace  Process  at 
the  beginning  of  the  simulation  run.  The  parameters  for  the 
Scenario  implied  by  these  requirements  are  printed  page  18  of  the 
analyze  report  in  Appendix  B. 
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7.4  ANALYZING  THE  MODEL 


To  run  the  model  through  a  simulation  test,  invoke  the  Analysis 
User  Interface  from  the  AISIM  READY  level.  For  this  example,  the 
simulation  will  not  be  interrupted  at  the  ends  of  periods,  nor 
will  graphs  be  defined. 

The  analyze  report  obtained  from  a  simulation  run  of  this  model 
appears  in  Appendix  B. 
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END  FUTRT 

EMO 


LOCAL  VARIABLES  OF  PROCESS  ROUTER 


H9-REQ  60  EXPONENT  HQRRATE 


SCENARIO  DEFINITION 


SIMULATION  TIME  =  3600000,00000  UNITS 


NUMERIC  VARIABLES 


MSG  522  521  2997.82  2426851.67  322496.42  538431.97 


SIMULATION  TIMC  =  3600000.00000  UNITS 
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(  BUST  0.  .291  . 454  0.  1.000 

BUSY  TIME  8011.824  7527.494  1220.701  16274.992 
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